Implement builder interface for SelectorParams.

[aagbotemi]

Building transactions through SelectorParams currently gets no feedback if they accidentally create dust outputs or include multiple OP_RETURN outputs. These mistakes only surface at relay time with opaque node rejections.
Implement a builder interface for SelectorParams that validates target outputs against configurable mempool standardness rules, cathching dust recipients, multiple OP_RETURN outputs, oversized OP_RETURN scripts, and missing required fields at construction time.

Proposed solution
Introduce a SelectorParamsBuilder as a separate type that validates and produces SelectorParams.
The SelectorParams::builder() chains methods and call .build() which validates against a configurable MempoolPolicy struct.

Context
See selector.rs L20–L27

[aagbotemi]

Update on the design while I've been implementing this. The OP_RETURN rule in the TODO ("error on multi OP_RETURN outputs") is no longer accurate under Bitcoin Core v30 bitcoin/bitcoin#32406

v30 did two things: it removed the single-OP_RETURN restriction entirely, and it changed -datacarriersize from a per-output cap to a budget spread across all OP_RETURN outputs in a transaction. The default was raised to 100,000 bytes, which effectively uncaps at default settings.
That leaves a policy choice for check_standardness:

1. Match v30 defaults - 100,000 bytes.
2. Match the pre-v30 - 83 bytes.
3. Make it configurable on SelectorParams.

I've implemented option 1 so far.

[notmandatory]

This issue was also flagged by an automated redteam report, details attached and below.

2026-08-13-bdk_wallet-unstable-create-psbt-dust-zero-recipients.zip

Unstable bdk-tx create_psbt accepts dust and zero-value recipients — validation regression vs stable create_tx

• Project: bdk_wallet
• Commit/version: 3.1.0 line @ 49f7955c34d1f558ca3566656faa8b17acffba1c (master, 2026-08-13)
• Category: bug / protocol footgun
• Severity: Low — non-standard unrelayable outputs; gated behind --cfg bdk_wallet_unstable + opt-in bdk-tx feature
• Reproduction: confirmed — poc/ (RUSTFLAGS="--cfg bdk_wallet_unstable" cargo test --release --test poc_bdktx)
• Confirmed: dynamically-reproduced
• Attacker model: none required (caller error, or an application passing end-user amounts into the unstable builder)
• Default config affected: no (unstable cfg + bdk-tx feature required)
• Reported upstream: no
• Disclosure: security@bitcoindevkit.org (see statistics/disclosure-contacts.md entry for bdk_wallet; source https://github.com/bitcoindevkit/bdk_wallet/blob/master/SECURITY.md, checked 2026-08-13)

Summary

The stable TxBuilder path rejects dust recipients with CreateTxError::OutputBelowDustLimit (src/wallet/mod.rs:1452) and rejects zero-value non-OP_RETURN outputs. The unstable bdk_tx-based create_psbt path (src/wallet/mod.rs:3192-3274, create_psbt_with_rng; recipients collected in src/psbt/params.rs:305-313) performs neither check; the dependency bdk_tx 0.2.0 carries an unimplemented TODO at src/selector.rs:26-31 ("Error if recipient is dust"). PoC output:

create_psbt ACCEPTED dust recipient: outputs=[100, 49758]
create_psbt ACCEPTED zero recipient: outputs=[49858, 0]

Both transactions are non-standard and will not relay; the dust output may additionally be uneconomical/unspendable.

Attacker model

No attacker required. The risk is an application adopting the new (explicitly unstable) API and losing the standardness validation the stable builder provided — a regression trap for migrators.

Exploit chain

1. Consumer enables bdk-tx + --cfg bdk_wallet_unstable and migrates from build_tx() to create_psbt(PsbtParams).
2. PsbtParams::add_recipients accepts a 100-sat (or 0-sat) P2WPKH recipient without error.
3. create_psbt returns a PSBT carrying the invalid output; the wallet signs/finalizes it.
4. Broadcast fails standardness checks (dust); funds are not lost but the payment flow stalls, and any dust output that does get mined is effectively burned.

Root cause

Recipient validation was implemented in the legacy builder (create_tx) and not ported to the new bdk_tx-backed path; the upstream TODO acknowledging it is unimplemented in the pinned bdk_tx 0.2.0.

Why defenses fail

• The only guard on the unstable path is NoRecipients (mod.rs:3198-3203); nothing inspects recipient amounts.
• The stable-path check cannot help because the unstable path does not call it.

Impact

Unbroadcastable transactions / stuck payment flows; at worst economically-burned dust outputs. Limited by the unstable gating.

Preconditions / limitations

• Consumer opts into bdk_wallet_unstable + bdk-tx feature. Stable create_tx users are unaffected.

Suggested fix

Implement the bdk_tx TODO (reject dust recipients at selection time) and/or re-validate recipients in create_psbt_with_rng with an OutputBelowDustLimit equivalent before returning the PSBT. Add parity tests between the two builders.

Reproduction

poc/ — edit Cargo.toml path deps to a local bdk_wallet checkout at the commit above (needs the bdk-tx feature), then RUSTFLAGS="--cfg bdk_wallet_unstable" cargo test --release --test poc_bdktx -- --nocapture.

Confidence

High — dynamically reproduced under the exact unstable configuration; stable-path validation contrasted line-by-line.