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...