feat(selection)!: declare sighash_type on Plan-derived inputs

[evanlinjin]

Closes #60.
Supersedes #69.

Description

The problem

Two issues with how PsbtParams::sighash_type worked.

1. The field itself wasn't very useful. It was a tx-wide uniform override. However, the realistic use cases for non-ALL sighashes are inherently per-input.

2. It didn't guard against the catastrophic Taproot case. Taproot signature size depends on sighash (SIGHASH_DEFAULT is 64 bytes and other Taproot sighashes are 65 bytes). A miniscript Plan has the sighash type pre-baked and Plan::satisfaction_weight() is only accurate if the signer uses the assumed sighash.

The solution

This PR adds an always-on safety auto-lock: any Plan whose Schnorr witness template includes a 64B signature gets TapSighashType::Default written, independent of declare_sighash.

We also replace PsbtParams::sighash_type with PsbtParams::declare_sighash: bool. When declare_sighash is set (default), SIGHASH_ALL is written to all PSBT inputs that are "weight-safe".

The new behavior is summarized below:

Plan's Schnorr placeholders	declare_sighash: false	declare_sighash: true (default)
Any 64B	TapSighashType::Default (forced)	TapSighashType::Default (forced)
All 65B	unset	TapSighashType::All
None (ECDSA)	unset	EcdsaSighashType::All

PSBT-derived inputs (Input::from_psbt_input) are never touched. They come in with their own sighash_type already set.

Callers needing non-ALL sighashes (SINGLE, NONE, *_ANYONECANPAY) set psbt.inputs[i].sighash_type directly on the returned PSBT. Plans needing non-ALL semantics on every key should be built with uniform TaprootCanSign::sighash_default = false so the safety lock doesn't fire.

Notes to the reviewers

This PR differs from #60's proposal.

The original issue suggested auto-writing DEFAULT only on uniformly-64B Plans (a plan can require multiple signatures with different sighash types). In this PR, a Plan with any 64B placeholder triggers sighash_type = DEFAULT.

• Rationale: Mixed sighash types in one Plan are uncommon in practice. We want to avoid under-funding at all costs whereas over-funding is fine.

The original issue proposed writing None as default for "weight-safe" inputs. This PR sets declare_sighash = true as default, so that ALL will be written.

• Rationale: BIP-174 requires finalizers to reject sigs that don't match a declared sighash_type - we use this as a defense. ALL/DEFAULT is what the super-majority of callers would want.

Alternative (rejected) solutions

• Placing a sighash_type field in Plan-based bdk_tx::Input - This is a PSBT-concern. In fact, input witness can have multiple signatures.

Scope creep

I leaned up the tests a little beforehand: dca56db

Changelog notice

Added:
- `PsbtParams::declare_sighash` which writes `sighash_type = ALL` to all "weight-safe" inputs. This is the default that the super majority of callers would want.

Changed:
- Plan-based `Input`s whose witness template contains at least one 64B Schnorr signature will have `sighash_type = DEFAULT` written for that input, regardless of whether `PsbtParams::desclare_sighash` is set.

Removed:
- `PsbtParams::sighash_type` as transaction-wide sighash type setting is not useful.

Before submitting

• I followed the contribution guidelines
• This PR breaks the existing API

[ValuedMammal]

Thanks for the detailed description. I was in favor of the original proposal in #60 - remove the sighash_type field and auto-write DEFAULT if the plan's weight assumption depends on it. The behavior should be clearly documented. I think sighash type shouldn't be part of PsbtParams at all but handled by the signer/coordinator.

[evanlinjin]

Thanks for the detailed description. I was in favor of the original proposal in #60 - remove the sighash_type field and auto-write DEFAULT if the plan's weight assumption depends on it. The behavior should be clearly documented. I think sighash type shouldn't be part of PsbtParams at all but handled by the signer/coordinator.

create_psbt plays the Creator + Updater roles, so PSBT_IN_SIGHASH_TYPE is its decision to make. The Signer role must honor what's declared, and Finalizers must reject signatures that don't match (they don't set such fields).

What's the motivation for PsbtParams::declare_sighash?

• declare_sighash == true is what most callers want. They want their signatures to cover the whole transaction and we use PSBT_IN_SIGHASH_TYPE to enforce it.
• declare_sighash == false - the caller saying "I want something custom, leave it to me". We still write DEFAULT for 64B Schnorr Plans because any other sighash will underfund the tx.

[notmandatory]

Concept ACK

I like the approach to defaulting to "safe" sighash ALL and leaving it up to the user to manually op-out of the default and set their non-typical sighash types.

The coding is well documented and easy enough to follow. But can you add a test for the mixed sighash type concern described in problem 2 ? I don't doubt it will pass but would be good to have a unit test to make sure it doesn't break in the future.

[evanlinjin]

@notmandatory I added the mixed sighash test!

[ValuedMammal]

NACK

[evanlinjin]

@ValuedMammal welcome to NACK, might need to formulate proper arguments 😅

[evanlinjin]

@ValuedMammal Let me present my reasoning clearly so it's easier for you to address. Here are my claims:

1. PSBT_IN_SIGHASH_TYPE is meant to be set by the Updater (as per BIP-174). Signers consume it, they don't decide it. create_psbt plays both the Creator and Updater roles.

2. Leaving PSBT_IN_SIGHASH_TYPE unset means the signer is free to use anything. BIP-174: "should sign using SIGHASH_ALL, but may use any sighash type they wish". A signer picking anything other than ALL/DEFAULT means inputs/outputs may be added/replaced.

3. Declaring sighash binds compliant signers. BIP-174: "Signatures for this input must use the sighash type".

4. The super-majority of callers want ALL/DEFAULT sighash types only. Therefore, we should have this as our default.

5. 64B Schnorr Plans must be locked to DEFAULT otherwise we risk underfunding the transaction which is dangerous.

6. declare_sighash: false preserves the "leave unset" behavior. Callers wishing for this behavior still have it.

Could you indicate which one you reject? Need to know what we are arguing about.