-
Notifications
You must be signed in to change notification settings - Fork 906
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
Never follow bitcoind backwards #3274
Never follow bitcoind backwards #3274
Conversation
tests/test_misc.py
Outdated
sync_blockheight(bitcoind, [l1]) | ||
l1.stop() | ||
|
||
# Now shrink chain (invalidateblock leaves 'headers' field) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tried it myself, and indeed the headers
remains unchanged after invalidateblock
, however if invalidateblock
is followed by a restart headers
will reset to the expected value. Maybe that's a more stable way of going backwards than blowing away the underlying directory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that would have been easier!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
e09d68d
to
528b975
Compare
Rebased to use the Decker technique for creating reorgs... |
time.sleep(5) | ||
assert l1.rpc.getinfo()['blockheight'] == 110 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be made into a wait_for
. Happy to fix it in a cleanup though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it can't: we want to make sure it's still at 110.
Seems we have a bit of collateral damage:
Other than that LGTM 👍 |
528b975
to
7cbfbc4
Compare
Thanks, fixed. I actually like the change in behavior (refusing to start) if you ask it to rescan from a not-yet-present block, so I've kept and tested that. |
7cbfbc4
to
10a74c7
Compare
This leads to all sorts of problems; in particular it's incredibly slow (days, weeks!) if bitcoind is a long way back. This also changes the behaviour of a rescan argument referring to a future block: we will also refuse to start in that case, which I think is the correct behavior. We already ignore bitcoind if it goes backwards while we're running. Also cover a false positive memleak. Changelog-Fixed: If bitcoind goes backwards (e.g. reindex) refuse to start (unless forced with --rescan). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
10a74c7
to
cdafcf3
Compare
Ack cdafcf3 Fixed all the test collateral damage. |
This solves the underlying reason why #3243 was such a problem!