docs(signers): what are the signoptions, what are they used for ?

[oleonardolima]

[ValuedMammal]

Feasibility of the sign options in the new sign_psbt API

Pre-flight validation guards — Easy and worth keeping

trust_witness_utxo: BDK adds this as a security check before any signing happens. The bitcoin Psbt::sign doesn't enforce this. It's just a pre-flight guard we can add before calling psbt.sign(). Still security-relevant against the SegWit fee-attack vector. Keep it.

allow_all_sighashes: Same story — BDK checks sighash types before signing to protect against being manipulated into signing something unexpected. Bitcoin's Psbt::sign will happily sign whatever sighash the PSBT specifies. Easy to add as a pre-flight check. Keep it.

Finalization control — Obsolete or split out

try_finalize: There's already a standalone finalize_psbt method. The caller can decide whether to finalize. Dropping this makes the API cleaner — signing and finalization are now separate concerns.

assume_height: Only used in finalize_psbt for timelock evaluation (verify this). If the new sign_psbt doesn't auto-finalize, this doesn't belong here at all. If we later add optional finalization, it belongs on finalize_psbt's own options, not the signing options. Move it.

Signer behavior — Infeasible with generic GetKey

allow_grinding: This controls how the ECDSA signature is computed (sign_ecdsa_low_r vs sign_ecdsa). The bitcoin Psbt::sign path uses whatever the GetKey gives it. We have no hook to inject this. The only way to support it would be to write a custom GetKey wrapper that applies grinding — potentially fragile.

tap_leaves_options and sign_with_tap_internal_key: Both are deeply embedded in BDK's InputSigner. The bitcoin Psbt::sign signs all reachable taproot code paths for the provided key. Filtering which leaves to sign requires controlling the signing loop itself (Do we want that?), which the GetKey abstraction doesn't allow.

[lambaaryan011]

Hi ,@ValuedMammal @thunderbiscuit I have a clear understanding of the SignOptions refactor. To summarize the approach:

=> Retain: Security-focused guards (trust_witness_utxo and allow_all_sighashes).

=> Remove: Finalization controls (try_finalize and assume_height) due to architectural constraints.

I am interested in implementing these changes and drafting the documentation for the remaining options. May I be assigned to this task?