Closed
Conversation
f3b05c7 to
a37c9df
Compare
|
Can I ask where these headers will be stored moving forward? I took a quick glance at the code diff but didn't see anything that jumped at me. I assume this is now the user's responsibility somehow? Just trying to make sure I'm staying on top of the big architectural changes coming down the pipe for Kyoto, at least in my rough mental model of things! |
Collaborator
Author
|
I was working on a description as you commented! @thunderbiscuit |
Collaborator
Author
|
While you're hanging out in this part of town, do you have an opinion on #445 @thunderbiscuit? |
|
Cool! I commented there. 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Given bitcoindevkit/bdk#1582, it seems as BDK will eventually be able to accept both
HeaderandBlockHashto theLocalChain. If it is assumed the underlying wallet will have block headers, not just hashes, then there is an opportunity to remove data redundancy.A future flow would look like:
User supplies a recent history of the headers they know about -> The node starts with this history, informing the user of any reorgs -> The node emits the last
Nheaders the user cares about -> The user stores these headers for the next syncBefore this goes in for certain, we will need to confirm that block headers can be stored/fetched from BDK
sqlite. Users of the library that do not use BDK will have to keep their own snapshots, but this is a great opportunity to reduce the maintenance scope. Pros outweigh the cons IMO