plan: add Plan::tap_sighash_default accessor

[evanlinjin]

Summary

Adds a public accessor on Plan that exposes the existing per-Schnorr-placeholder size assumption — recorded when the plan was built from TaprootCanSign::sighash_default — as a single Option<bool>.

impl<Pk: MiniscriptKey + ToPublicKey> Plan<Pk> {
    /// Returns whether the witness was sized assuming `SIGHASH_DEFAULT` (the
    /// 64-byte Taproot signature encoding).
    pub fn tap_sighash_default(&self) -> Option<bool>;
}

• Some(true) — every Schnorr placeholder is sized for a 64-byte signature (the SIGHASH_DEFAULT encoding).
• Some(false) — every Schnorr placeholder is sized for a 65-byte signature (any non-Default Taproot sighash flag).
• None — non-Taproot plans (signature size is invariant under the sighash flag for ECDSA), or mixed plans whose Schnorr placeholders have differing sizes — these cannot be expressed by a single uniform sighash policy per BIP-174.

Motivation

Callers building a PSBT from a Plan need to populate PSBT_IN_SIGHASH_TYPE consistently with the plan's witness-size assumption — otherwise weight estimates drift from reality. The information already lives inside the plan (on every Schnorr placeholder's size field); this just surfaces it as a single readable answer.

Concretely: bdk-tx is reworking per-input sighash handling and needs to derive the PSBT sighash policy from the plan rather than carrying separate state on its Input type (see bitcoindevkit/bdk-tx#69 for the full design). Without this accessor it would have to walk Plan::witness_template() and infer the bool from placeholder sizes, which leaks internals.

A 12.x backport is up at #950.
A 13.x backport is up at #952.

Test plan

• cargo test --lib tap_sighash_default — new test covers Default-Taproot, non-Default-Taproot, and non-Taproot (wsh) plans.
• cargo test --lib — full suite still passes (157 / 0 / 0).

🤖 Generated with Claude Code

[nymius]

This is a guess based on information which was available at the moment of providing the assets. Why not surfacing directly the SIGHASH value obtained from the assets?

[evanlinjin]

This is a guess based on information which was available at the moment of providing the assets. Why not surfacing directly the SIGHASH value obtained from the assets?

I agree we should expose what's available directly. But the asset model only tracks sighash to the extent it affects witness size and the detailed sighash type isn't carried. Look at CanSign: ecdsa. This is a plain bool with no sighash field at all, because every ECDSA sighash variant produces a same-sized DER signature. The Taproot side has sighash_default: bool only because Taproot is the one place sighash affects sig length (64 vs 65 bytes).

To expose without inferring, I can bubble TaprootCanSign::sighash_default: bool information up as a variant field changes in Placeholder. However that will be a breaking change and adds more complexity imo.

[apoelstra]

I agree that this method does not seem useful for the claimed motivation. PSBT_IN_SIGHASH_TYPE is supposed to have an actual sighash type and this does not provide one.

Also, if there are multiple sighash types, we ought to return a vector of them. Maybe we should return Result<sighashtype, Vec<sighashtype>> or something like that.