bitcoindevkit
Sync to specific block
Describe the enhancement
Currently, there is no way to sync a Wallet to a specific block (and no further).
One can specify an initial chain tip in a sync request, but there is no way to specify a target chain tip. A sync always ends with the current best tip.
There is no way to disconnect a wallet tip either, so syncing to current best tip and then disconnecting blocks is not possible (#1271, bitcoindevkit/bdk#1655).
It should be possible to either:
- Disconnect blocks from a
Wallet - Specify a target chain tip in a sync request
Use case
In an application that needs to keep a wallet in sync with some other component that updates on each new tip (eg. a mempool), an initial sync process is quite awkward:
- Load wallet
- Subscribe to
sequence/rawblock/hashblock - Sync wallet
- Sync other component to wallet tip
- Persist wallet
- Ignore tip updates older than wallet tip
- For each new tip, apply block to wallet and other component, and persist wallet
In particular, the requirement to sync a wallet to the current tip before anything else is a constraint on application architecture - it is more complex to perform initial sync concurrently, since a wallet may sync to a different tip than another component. If that other component also does not support disconnecting blocks, one needs to repeatedly attempt to sync each to the same block.
If specifying a target chain tip for sync was possible, an initial sync process could look like
- Load wallet
- Subscribe to
sequence/rawblock/hashblock - Get current best tip
- Sync & persist wallet, sync other component to best tip
- Ignore tip updates older than wallet tip
- For each new tip, apply block to wallet and other component, and persist wallet
If disconnecting blocks was possible, an initial sync process could look like
- Load wallet
- Subscribe to
sequence/rawblock/hashblock - Get current best tip
- Sync wallet, sync other component to best tip
- If wallet tip is behind best tip, connect blocks; If wallet tip is ahead, disconnect blocks
- Persist wallet
- Ignore tip updates older than shared tip
- For each new tip, apply block to wallet and other component, and persist wallet
Thanks for writing this up. I have some further questions.
Do you need the wallet to be able to sync up to a specific blockhash? Or is syncing up to a block height good enough?
Let's say the network tip is at height 1000 and we instruct the wallet to sync up to height 950. For the transactions in blocks 951 to 1000 and in the mempool, would your application be okay for them to just appear unconfirmed in the wallet?
Hello! What kind of responsibilities would these "other components" typically have in this context? (e.g., relying on confirmation status for rebroadcasting transactions, indexing txs, etc.) Just trying to better understand the use case.
Do you need the wallet to be able to sync up to a specific blockhash? Or is syncing up to a block height good enough?
Syncing to a specific blockhash seems preferable, although it is likely that a block height is good enough - one almost always intends to sync to the active chain. Is syncing to a particular block height easier to implement for some reason?
For the transactions in blocks 951 to 1000 and in the mempool, would your application be okay for them to just appear unconfirmed in the wallet?
Yes, this is fine
Hello! What kind of responsibilities would these "other components" typically have in this context? (e.g., relying on confirmation status for rebroadcasting transactions, indexing txs, etc.) Just trying to better understand the use case
An example would be a block template builder - one might wish to handle payouts, receiving address for coinbase txs, etc when constructing a block template. Manually keeping a wallet in sync with a mempool would be nice here