onchaind: replay using real block data, not db #7343
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
92842a3 to
c5fba12
Compare
c5fba12 to
449899d
Compare
|
I rebased this, and added more protections against gossipd getting out of sync (if it doesn't process all the spent utxos before we stop). |
e977b18 to
34991a2
Compare
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…g replay. We start by telling onchaind about the funding spend, and anything which spends it, and it tells us the txids it *doesn't* want to watch any more. We're going to use a separate set of watches for the replay case: this implements that code. Once we're caught up, we convert any remaining watches to normal ones to follow future blocks. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And we hook in the replay watch code. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: `onchaind` can miss conclusion of final txs in some cases, will now replay independently.
Now we do replay, we don't need the others. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If it gets really far behind, then we restart, it could miss some. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This may help the cases we see where gossipd doesn't realize channels are closed (because of shutdown before it processed the closing). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: `gossipd` will no longer miss some channel closes on restart.
Useful if it's only to be used for the duration of the callback. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means it always tells us explicitly whether to keep watching or not, and we know it's processed it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…lay. Christian noted that if we don't do this we could flood onchaind with messages: particularly in Greenlight where the HSM (remote) may delay indefinitely, so onchaind doesn't process messages. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
34991a2 to
eea3c90
Compare
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.
We have a report of onchaind not sweeping properly. It seems to be missing an output during replay, which makes sense since Greenlight restarts nodes (a lot!).
See Blockstream/greenlight#433
I've also got a similar issue on my node, but I assumed that was me corrupting the database by editing it long ago. I will, however, test this fix on my node too...