Fetch block from a peer if we don't have it #7240
Merged
Conversation
This file contains 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
This allows us to intercept getblock on a non 0 exit when the block was not found. We fill this with something meaningull in future commits. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We move the `geblock` call into a separate function. This allows us to call if from various places in the future. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We introduce the peers array that contains the known set of connected peers for future reference in case that we couldn't find the block we are looking for. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
In the case that we have peers left in the peers array and that we could not find the block yet, we ask the next peer for the desired block. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
`getblockfrompeer` was introduced in v23.0.0, we want to skip this path if the version of bitcoind used is below that. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Changelog-Changed: Plugins: bcli: Add a path that tries to fetch blocks from a peer if we can not find them locally. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
|
I would also really like some tests! This can be done using our inbuilt mocks for bitcoind; you can give a made-up blockhash, let it fail (since there are no peers), but also can fake up some peers and check it does indeed iterate through them. |
|
@rustyrussell I am a bit confused about the tests. There are already a few tests using a mocked bitcoind that test the peer iteration in |
Using `getblockfrompeer` requires a version equal or above 23.0.0 Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
It is simpler to just iterate through the peerlist backwards. Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Hmm, how did I miss that commit? Sorry, these look good! |
Closed
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.
This PR adds a path in the
bcliplugin that utilizesgetblockfrompeerto try to fetch a block from a peer in case that we don't know about the block. This is something that happens when core lightning tries to fetch a block from bitcoind that has already been pruned by bitcoind.getblockfrompeerhas been introduced inv23.0.0. The call asks a given peer for a block that the local node does not know about. Even thoughgetblockfrompeerdoes not make any guarantees about whether the block will be fetched (or pruned again right away), the success probabilities are really high if we just try long enough.Here is a brief description about what happens now if core lightning asks for a block
a) get blockhash for height x
b) try to get block from bitcoind:
resolves #7201