bdk_wallet 3.0

[reez]

This issue is to track items that we want to implement or test in the next bdk_wallet release (likely 3.0 but maybe 2.3):

• remove temp fix fix: catch esplora panics and return parsing error #863 (review) if upstream bdk_esplora adds fixes like Remove panic from stop gap scan loop bdk#2053 (comment)
• make the change descriptor an option on the Wallet::load constructor (breaking change, 3.0) Enable loading of single-descriptor wallets #897

Anyone is free to add/edit this list

[reez]

2.4 might have signing

[reez]

bitcoindevkit/bdk_wallet#388

expose apply_unconfirmed_txs_events and apply_evicted_txs_events

event::wallet_events may be transitional until CanonicalView::diff so not sure if we should defer it or not based on how quickly that comes

[reez]

rc1 open pr bitcoindevkit/bdk_wallet#395

[reez]

rc1 open pr bitcoindevkit/bdk_wallet#395

rc merged

[reez]

cool things like bitcoindevkit/bdk#2081 coming in 3.0?

[reez]

rc1 branch https://github.com/reez/bdk-ffi/tree/rc1 wip

opened up issue and pr on kyoto for something I think(?) we need

• Issue: Relax bdk_wallet dependency for 3.0.0-rc.1 compatibility bdk-kyoto#154
• PR: chore: update bdk_wallet compatibility bdk-kyoto#155

[reez]

bitcoindevkit/bdk_wallet#388

expose apply_unconfirmed_txs_events and apply_evicted_txs_events

event::wallet_events may be transitional until CanonicalView::diff so not sure if we should defer it or not based on how quickly that comes

Landed upstream in bdk_wallet and ships in 3.0.0-rc.1 so I exposed these in my rc1 branch. This only wraps the public wallet method and existing WalletEvent mapping in bdk-ffi without exposing lower-level event internals that may still change later.

[reez]

rc1

• Wallet::apply_unconfirmed_txs_events
• Wallet::apply_evicted_txs_events
• Wallet::checkpoints()
• Wallet::start_sync_with_revealed_spks_at
• Wallet::start_full_scan_at
• TxBuilder::sighash
• BumpFeeTxBuilder::sighash

Notes:

TxBuilder::sighash / BumpFeeTxBuilder::sighash
Upstream explicitly warns "Use this option very carefully" in bdk_wallet. I exposed it for parity since bdk-ffi already exposes PSBT input sighash_type and signing-related sighash controls, but I’d be fine dropping it if we want to keep the FFI surface more conservative.

[reez]

Decided to just implement/expose everything, not because we will necessarily merge, but so we can give feedback upstream if needed based on shape of apis as it relates to implementing these new things in bindings...

[reez]

rc1

• TxBuilder::add_foreign_utxo_with_sequence
• TxBuilder::ordering / BumpFeeTxBuilder::ordering
• ChangeSet.locked_outpoints
• Wallet::list_locked_outpoints / list_locked_unspent / is_outpoint_locked / lock_outpoint / unlock_outpoint

Notes:

TxBuilder::add_foreign_utxo_with_sequence
This inherits all the caveats of the already-experimental foreign-UTXO API. The extra sequence parameter is straightforward, but the tricky part is still the underlying foreign-input correctness and the only_witness_utxo / non_witness_utxo behavior.

TxBuilder::ordering / BumpFeeTxBuilder::ordering Only Shuffle and Untouched are exposed in FFI. Upstream TxOrdering::Custom is Rust-closure-based, so it did not map cleanly to UniFFI.

ChangeSet.locked_outpoints
Represented in FFI as HashMap<Arc<HashableOutPoint>, bool>. I also kept the old from_aggregate constructor stable and added from_aggregate_with_locked_outpoints, so adding persistence support did not force a constructor signature break.

Wallet::list_locked_outpoints / list_locked_unspent / is_outpoint_locked / lock_outpoint / unlock_outpoint
Main nuance here is persistence. These wallet methods only felt complete once ChangeSet.locked_outpoints was also exposed in types.rs (line 1189), types.rs (line 1222), and types.rs (line 1338), because otherwise the FFI persistence surface would not round-trip lock state. That is why I implemented the wallet methods and the changeset support together rather than as separate patches.

[reez]

rc2

• Persister::get_pre_v1_wallet_keychains

Notes:

Persister::get_pre_v1_wallet_keychains
I did not mirror the upstream raw rusqlite::Connection API directly, I exposed it through the existing sqlite-backed Persister surface and return a FFI-friendly PreV1WalletKeychain record plus a structured PreV1MigrationError. Custom persisters return SqliteOnly, since this helper is specifically about pre-v1 sqlite wallet migration.