Add bitcoind_rpc chain source module.#1041
Add bitcoind_rpc chain source module.#1041notmandatory merged 14 commits intobitcoindevkit:masterfrom
bitcoind_rpc chain source module.#1041Conversation
a0cb7f8 to
ae3ee39
Compare
658259c to
b5b2367
Compare
019f9f1 to
19e51d4
Compare
19e51d4 to
18374e7
Compare
LLFourn
left a comment
There was a problem hiding this comment.
I've made some comments. It looks awesome. I think this will be a "flagship" example on how to use bdk so I think we should spend the time to get it right. The block data processing pipeline is too complicated for what the problem is. I think IndexedTxGraph needs to be able to process block data and filter out what's relevant itself. This is needed for CBF block processing as well so calling out to weird helper methods in the bitcoind_rpc crate seems counter productive.
18374e7 to
169c21e
Compare
|
@evanlinjin this looks like a really powerful way to sync with a core node. I read through the code and I think I understand the state-model approach within the You look to be covering the main test scenarios, 1. sync blocks before and after reorg, 2. sync txs in mempool and after being included in a block. Is it worth adding a test to verify confirmed tx are unconfirmed after a reorg? |
9e873b5 to
e1a9124
Compare
|
@danielabrozzoni Sorry, I'm going to ignore your nits due to how long this PR is taking. We can revise I also think we should put |
LLFourn
left a comment
There was a problem hiding this comment.
Thanks this looks excellent. It would be nice to know why it's taking 20s before merging though? Is it a function of the size of the db file -- how big is it?
|
@LLFourn the file is 104MB, with a start height of 778,000 UPDATE: Okay I accidentally called UPDATE 2: Yeah with these settings, when a wallet is fully synced, loading from db takes less than 100ms. |
So you can pass in the esplora/electrum/bitcoind_rpc server details in the example. Co-authored-by: LLFourn <[email protected]>
This is useful for block-by-block chain sources. We can determine the tx's anchor based on the block, block height and tx position in the block.
* `CheckPoint::from_header` allows us to construct a checkpoint from block header. * `CheckPoint::into_update` transforms the cp into a `local_chain::Update`.
Co-authored-by: Steve Myers <[email protected]>
For `IndexedTxGraph`:
- Remove `InsertTxItem` type (this is too complex).
- `batch_insert_relevant` now uses a simple tuple `(&tx, anchors)`.
- `batch_insert` is now also removed, as the same functionality can be
done elsewhere.
- Add internal helper method `index_tx_graph_changeset` so we don't need
to create a seprate `TxGraph` update in each method.
- `batch_insert_<relevant>_unconfirmed` no longer takes in an option of
last_seen.
- `batch_insert_unconfirmed` no longer takes a reference of a
transaction (since we apply all transactions anyway, so there is no
need to clone).
For `TxGraph`:
- Add `batch_insert_unconfirmed` method.
Instead of inserting anchors and seen_at timestamp in the same method, we have three separate methods. This makes the API easier to understand and makes `IndexedTxGraph` more consistent with the `TxGraph` API.
Instead of comparing the blockhash against the emitted_blocks map to see whether the block is part of the emitter's best chain, we reduce the `last_mempool_tip` height to the last agreement height during the polling logic. The benefits of this is we have tighter bounds for avoiding re- emission. Also, it will be easier to replace `emitted_blocks` to a `CheckPoint` (since we no longer rely on map lookup).
* `bdk_chain` dependency is added. In the future, we will introduce a separate `bdk_core` crate to contain shared types. * replace `Emitter::new` with `from_height` and `from_checkpoint` * `from_height` emits from the given start height * `from_checkpoint` uses the provided cp to find agreement point * introduce logic that ensures emitted blocks can connect with receiver's `LocalChain` * in our rpc example, we can now `expect()` chain updates to always since we are using checkpoints and receiving blocks in order
vladimirfomene
left a comment
There was a problem hiding this comment.
Great work @evanlinjin ! Just a couple of questions and nits.
|
|
||
| /// The latest first-seen epoch of emitted mempool transactions. This is used to determine | ||
| /// whether a mempool transaction is already emitted. | ||
| last_mempool_time: usize, |
There was a problem hiding this comment.
Why define this as usize? Can we have it as u64 to avoid conversion later?
| /// that the block is no longer in the best chain, it will be popped off from here. | ||
| last_cp: Option<CheckPoint>, | ||
|
|
||
| /// The block result returned from rpc of the last-emitted block. As this result contains the |
There was a problem hiding this comment.
I think using GetBlockResult will make this sentence clearer.
| /// To filter out irrelevant transactions, use [`batch_insert_relevant_unconfirmed`] instead. | ||
| /// | ||
| /// [`batch_insert_relevant_unconfirmed`]: IndexedTxGraph::batch_insert_relevant_unconfirmed | ||
| pub fn batch_insert_unconfirmed( |
There was a problem hiding this comment.
When will this be useful? Can we add docs around when a user will want to use this API?
There was a problem hiding this comment.
When we want to track transactions, but don't want to filter them out.
* avoid holding mutex lock over io * document `CHANNEL_BOUND` const * use the `relevant` variant of `batch_insert_unconfirmed` * print elapsed time in stdout for various updates
Also better docs for `Emitter` fields.
notmandatory
left a comment
There was a problem hiding this comment.
Re ACK 85c6253
I don't see any critical issues remaining and any final nits can be fixed in follow-up PRs.
Description
This PR builds on top of #1034 and adds the
bitcoind_rpcchain-src module and example.Notes to the reviewers
Don't merge this until #1034 is in!
Changelog notice
bitcoind_rpcchain-source module.example_bitcoind_rpcexample module.AnchorFromBlockPositiontrait which are for anchors that can be constructed from a given block, height and position in block.IndexedTxGraphandTxGraphfor batch operations and applying blocks directly.CheckPointfor easier construction from a blockHeader.Checklists
example_bitcoind_rpc: addlivecommand.CheckPoint.All Submissions:
cargo fmtandcargo clippybefore committingNew Features: