Updated design for this PR.

After working through it, the per-Input sighash API turns out to be the source of the problem rather than a feature. Replacing it with a per-PSBT-input policy on PsbtParams.

The problem

For Taproot, signature size depends on sighash: 64 bytes for SIGHASH_DEFAULT, 65 bytes for anything else. Miniscript's Plan bakes this assumption in at construction time (via TaprootCanSign::sighash_default), and Plan::satisfaction_weight() is only accurate if the signer actually uses the assumed sighash.

Input::set_sighash_type introduces sighash state on Input independent of the Plan it was built from, so the two can disagree. The disagreement is silent — weight estimates become wrong, and coin selection drifts off.

Why sighash belongs at the PSBT layer, not on Input

BIP-174 treats sighash as a per-PSBT-input policy:

"The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type."

And when unset:

"If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish."

One input, one sighash policy, enforced at finalization. Input in bdk-tx describes what is being spent and how it can be satisfied. The sighash policy is a property of the constructed PSBT, not of the spend description — so it belongs in PsbtParams.

Required upstream miniscript change

To make the validation below feasible, we need a small additive accessor on Plan that surfaces the existing TaprootCanSign::sighash_default state:

impl Plan {
    /// For Taproot plans, returns whether the witness was sized assuming `SIGHASH_DEFAULT`.
    /// Returns `None` for non-Taproot plans (signature size is sighash-invariant).
    pub fn tap_sighash_default(&self) -> Option<bool>;
}

Implementation walks self.template and returns based on the size of the first SchnorrSigPk{,Hash} placeholder. Mixed sizes (different keys built with different TaprootCanSign::sighash_default) are pathological and not expressible via a single PSBT sighash field — will either debug-assert uniformity or surface as a third state. Will open the miniscript PR alongside this one.

Proposed design

1. Revert the per-Input sighash API. Drop Input::set_sighash_type and Input::sighash_type. Input carries no sighash state.

2. Add a per-input sighash override on PsbtParams:

pub struct PsbtParams {
    // ... existing fields ...

    /// Per-input sighash overrides, keyed by previous outpoint.
    ///
    /// Applies to Plan-based inputs only. PSBT-based inputs carry their own
    /// `sighash_type` field via their embedded `psbt::Input` and are not affected.
    ///
    /// For each entry, the value must be consistent with the corresponding
    /// Plan's witness-size assumption; `create_psbt` errors on mismatch.
    pub sighash_type: BTreeMap<OutPoint, PsbtSighashType>,
}

3. Centralize all sighash handling in create_psbt. For each Plan-based input, derive the PSBT input's sighash_type field from the override map and the Plan's witness-size assumption (using the upstream accessor above):

PSBT-based Inputs (built via Input::from_psbt_input) are unaffected — their embedded psbt::Input already owns its sighash_type field. The map applies only to Plan-based inputs. Stray map entries for outpoints not in the selection are ignored.

Net effect

• Input is purely a spend description, cannot carry inconsistent sighash state.
• All sighash logic lives in one place (create_psbt), one rule per case.
• Default-Taproot Plans get safe auto-lock with zero caller ceremony.
• Non-Default-Taproot Plans force the caller to declare a specific flag — loud failure, not silent fee drift.
• ECDSA Plans are unconstrained, matching reality.

Is this PR complete? I agree with the code here, but I wouldn't relay on a witness guessing scheme for extracting the SIGHASH type in the Plan variant.

It is not complete, waiting on upstream changes. Where did you think we were guessing the sighash type?

Sometimes plan is based on Sighash DEFAULT - if the resultant tx uses anything else, the feerate/fee will be different to what CS assumed. The idea is to error on inconsistency.