Skip to content

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

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?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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