Skip to content

Clarification: how should addr(SH_ADDRESS) be treated for dust? #12

@rodionmish

Description

@rodionmish

Hi! I’m trying to understand the intended behavior.

In @bitcoinerlab/descriptors, the comment says that when a descriptor is addr(address) and the address is SH-type, it’s assumed to be Segwit sh(wpkh(...)) (nested).

https://github.com/bitcoinerlab/descriptors/blob/9b288e7719478c42fcb97bc36bc78f04a069878d/src/descriptors.ts#L1008

     * Whether this `Output` is Segwit.
     *
     * *NOTE:* When the descriptor in an input is `addr(address)`, it is assumed
     * that any `addr(SH_TYPE_ADDRESS)` is in fact a Segwit `SH_WPKH`
     * (Script Hash-Witness Public Key Hash).
     * For inputs using arbitrary scripts (not standard addresses),
     * use a descriptor in the format `sh(MINISCRIPT)`.
     *

In @bitcoinerlab/coinselect, dust.ts uses a fallback input weight of native P2WPKH = 272 wu (~67 vB) when the input weight is unknown for addr(TR|SH|WSH):

(

// When sending to scripts (such as TR, SH, or WSH) using an addr() descriptor,
)

For addr(SH_ADDRESS), should the default assumption be nested sh(wpkh) or native p2wpkh?
For compatibility with Bitcoin Core’s GetDustThreshold (which treats P2SH outputs as non-witness and adds a 148 vB P2PKH input), do you recommend matching Core, or sticking with your current fallback?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions