nakamoto as Compact Block Filter Blockchain#751
nakamoto as Compact Block Filter Blockchain#751rajarshimaitra wants to merge 6 commits intobitcoindevkit:masterfrom
Conversation
9fe539c to
a62a8d6
Compare
| nakamoto-net = { git = "https://github.com/cloudhead/nakamoto.git", branch = "master", optional = true } | ||
| nakamoto-net-poll = { git = "https://github.com/cloudhead/nakamoto.git", branch = "master", optional = true } | ||
| nakamoto-p2p = { git = "https://github.com/cloudhead/nakamoto.git", branch = "master", optional = true } | ||
| nakamoto-common = { git = "https://github.com/cloudhead/nakamoto.git", branch = "master", optional = true } |
There was a problem hiding this comment.
You should be able to just import the nakamoto crate. It exposes these externally.
There was a problem hiding this comment.
Thanks for the tip.. I missed it.. Yes that's much more cleaner..
| transactions, | ||
| } => { | ||
| let timestamp = header.time; | ||
| for tx in transactions { |
There was a problem hiding this comment.
Note that all transactions of the matching block are included here, so you have to make sure to discard the ones you aren't interested in.
There was a problem hiding this comment.
We are actually handling that in the add_tx itself.. So any unrelated transaction will not get added in the db.. But ya the will be iterated over here but with not much extra over head as some basic if let statements in add_tx won't trigger for them. Maybe there's a better way to organize this, but for start it made sense to consolidate all transaction conflicts and addition logic in single place in add_tx..
Here we are just checking if the transaction hasn't been already processed by us..
| .collect::<HashSet<_>>(); | ||
|
|
||
| for txid in db_txs { | ||
| unconfirm_tx(database, &txid)?; |
There was a problem hiding this comment.
Note that nakamoto should already be emitting a TxStatus::Reverted for each tx in a reverted block, so you shouldn't have to handle it here.
There was a problem hiding this comment.
Hmm okay makes sense.. We still handle reverted cases in TxStatus::Reverted.. I am commenting this section out for now..
| debug!("Sync complete at : {}", height); | ||
| self.last_sync_height.set(height as u32); | ||
| break; | ||
| } |
There was a problem hiding this comment.
I assume you have another mechanism to restart the event loop when a new block header is received.
There was a problem hiding this comment.
No, this is basically a hack to stop the sync loop for the reorg tests in regetst.. Ideally an invalidateblock call on the regtest should also update the tip height, and the sync should automatically stop at the new tip height, but that wasn't happening.. So instead this hack is to force stop the sync.. This is feature gated as test, and cannot be used in production..
| } | ||
| TxStatus::Reverted => { | ||
| debug!("Transaction reverted due to reorg: txid : {}", txid); | ||
| let _ = unconfirm_tx(database, &txid)?; |
There was a problem hiding this comment.
FYI, nakamoto will re-announce reverted transactions. I don't think we fire another event for them other than this one (but we could).
There was a problem hiding this comment.
I think this transaction reversion event should be sufficient to catch them..
|
Thanks @cloudhead for the review and suggestion.. It seems the structure of the crate has changed in recent master.. So I pinned the rev to |
|
@thunderbiscuit this now includes |
ef6328e to
d190bbb
Compare
There was a problem hiding this comment.
Hey Raj! So I'm trying to expose this in the bindings and it surfaces two small things: (1) I think the names for the other blockchain config structs are slightly different, (2) the fields in the config struct are currently private but I'd need access to them.
To get an idea for how we use the config structs (and how we wrap them up slightly, note the ElectrumBlockchainConfig to ElectrumConfig same for the Esplora) you can take a look at lines 98ish to 225ish of this source file.
|
@thunderbiscuit updated as suggested.. |
|
One more extra commit is added to disable to existing compact_filters logic, so we don't need to unnecessarily build rocksdb and other stuffs not used for nakamoto client.. |
|
Working on the FFI integration here: bitcoindevkit/bdk-ffi#207 |
This commit adds the nakamoto blockchain into the current blockchain test frameworks. Uses a lot of feature gate and scaffolding to handle special behaviors of CBF type backend.
Include CbfNode in AnyBlockchain enum Impl ConfigurableBlockchain for CbfNode
This commit comments out existing compact filters module so only nakamoto dependencies get compiled with compact_filters features.
|
Hey, we are in the process of releasing BDK 1.0, which will under the hood work quite differently from the current BDK. For this reason, I'm closing all the PRs that don't really apply anymore. If you think this is a mistake, feel free to rebase on master and re-open! |
Description
An implementation of nakamoto as a BDK Blockchain to serve as an alter BIP157 syncing mechanism.
Commit 1 : adds a new module
src/blockchain/compact_filters/nakamoto.rswhich defines aCbfNodestruct which holds thenamakoto-clienthandlers. Which the implementsBlockchaintraits. 222a2b4Commit 2 : Integrates the
CbfNodebackend with the bdk's blockchain test framework.Notes to Reviewers
The current CI tests won't work because nakamoto doesn't support our MSRV. Though you can run the modified tests in your local with toolchain 1.63 or higher.
Few of the tests are intermittently failing and needs further investigation. But overall this PR is ready for review of to be used for testing..
Thanks for all the help and support from @cloudhead and others who pitched in for various fixes in upstream.
Checklists
All Submissions:
cargo fmtandcargo clippybefore committing