-
Notifications
You must be signed in to change notification settings - Fork 7
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
Regtest genesis block timestamp is newer than subsequent blocks upon restart. #144
Comments
I ran into a related problem when running
This is not a huge issue in my opinion. |
Let's move block validation on startup discussion to #146. I agree regtest digest changing is not top priority. Though I do hope we make a fixed regtest genesis block before launch, to avoid these kinds of confusions/issues. For reference, I wanted to be certain that bitcoin-core has a fixed regtest genesis block, so I asked about it on stackexchange, and it does. We don't always have to follow bitcoin's lead, but I think this issue is pointing out there is a good reason for it, and also the fact that different apps will generate different regtest from eachother, such as I initially encountered with the block-explorer. |
Now that we've changed |
To reproduce:
note: requires 3e21a69 or newer for neptune-cli
Notice that the timestamp for block 0 pre-dates that of block 1. In this case by 5 minutes. In actuality, they were mined nearly in the same second, but the genesis block gets rounded down to nearest 10 minutes.
shut it down. ctrl-c or
neptune-cli shutdown
and note the time.wait 10 minutes, at least.
restart. no need to mine this time.
Note that the genesis timestamp is now larger than block 1. Also, the genesis digest has changed since the first time we ran neptune-core. (bf4b52a6d.. != 04935d4fe)
Analysis
This is an unintended consequence of using a dynamic timestamp for RegTest when creating the genesis block. This timestamp is floored down to the nearest 10 minutes.
The genesis block is never stored in a DB (afaik). As such, upon any restart after 10 minutes, a new genesis block is created.
Surprisingly, this situation is not detected as an error and the rest of the blockchain is loaded. The end result is that we have an invalid blockchain, with block1's parent-hash being different from the (new) genesis block.
I see at least two problems here:
For reference, here is the start of my log from the 2nd run. Note that there are no warnings or errors, and we load block 19 (tip) just fine.
The text was updated successfully, but these errors were encountered: