-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create LocalChain with genesis block hardwired for Network #1079
Comments
I'm taking a shot at this one :) |
What is the benefit of this and what is the planned API? |
I think the idea is that you can create a new LocalChain prepopulated with the appropriate genesis BlockId and this would prevent blocks from the wrong chain from being added to it. Is that what you had in mind @evanlinjin ? |
So this would be an optional kind of constructor like |
The rationale is described here: #1116 (comment) |
Describe the enhancement
LocalChain
will no longer implementDefault
. Instead, it will require a genesis hash to construct. This ensures that we will always have at least one checkpoint inLocalChain
(the genesis block).ChainOracle::get_chain_tip
will no longer need to return anOption
as we guarantee that we at least have the genesis block.Implementation details
LocalChain
will need to ensure that the genesis checkpoint cannot be replaced while updating. I think it would also make sense to persist the genesis checkpoint, this way recovery from persistence will fail with the wrong genesis hash.Changes to chain-source crates
Any method that takes in an option of a checkpoint should just take in the checkpoint (no
Option
).For the
bdk_bitcoind_rpc
crate, instead of emitting(u32, Block)
, we want to emit(CheckPoint, Block)
. This is because for the first emission (given a start height that is >1), we can no longer rely on the block header to construct the chain update (since we now need to connect to the genesis block!). Additionally, if there is no previous checkpoint (Emitter::last_cp
), the first emission's checkpoint should also include the genesis block.Use case
This fixes #1107 without requiring methods of
TxGraph
andIndexedTxGraph
to take in anOption
ofBlockId
as the static block.The additional benefit of this is that if the caller accidentally updates
LocalChain
with dat from the wrong network, the update can never connect (since the genesis block cannot be replaced).Additional context
Suggested by @evanlinjin in bitcoindevkit/.github#72.
Comment on
PR#1116
: #1116 (comment)The text was updated successfully, but these errors were encountered: