feat: Relativize genesis block

aszepieniec commented 6 months ago

Make Block::genesis_block take Network as a parameter. Every network has its own genesis block.
Hardcode the timestamp of the genesis block for all Network variants except RegTest.
Timestamp for RegTest is now but rounded down to the prior round point of 10 minutes. This may cause tests to fail, in particular if the test in question calls Block::genesis_block twice and on opposite sides of a round point in time. This happens with very small but nonzero probability.
Add variants Beta and Main to enum Network.
Harmonize timestamps: now use Timestamp for consensus-critical timestamps.

dan-da commented 6 months ago

why not hard-code regtest genesis-block timestamp also?

aszepieniec commented 6 months ago

why not hard-code regtest genesis-block timestamp also?

You might be able to find a configuration along those lines that works. It's not impossible, just difficult.

The challenge is to find the right timestamp to set it to. If it is in the future, tests will fail because you shouldn't be able to send and receive future blocks. If it is in the past, the automatically updated network parameters (right now only difficulty) are updated with respect to a unrealistically large and unfixed block interval.

dan-da commented 5 months ago

@aszepieniec I merged master into your branch so we can get this merged soon.

dan-da commented 5 months ago

lgtm. Definitely a win to have a proper Timestamp type. I'm seeing some errors validating newly mined blocks, but those were already happening, so this PR doesn't seem to blame. I'm going to merge now as-is.

dan-da commented 5 months ago

With regards to regtest having a non-fixed timestamp, yesterday I encountered a real-world issue with this.

In building a block explorer, the explorer needs to work with any network. I initially added a config option for this. The explorer has access to Block from neptune-core model, and so is able to call Block::genesis_block() directly in order to determine the genesis block hash, which is then output as hex and embedded in an html link. When a user clicks on that link, the explorer makes an RPC call to neptune-core to lookup the (genesis) block by digest. The rpc call returns a not-found because neptune-core generated a different regtest genesis block than the block-explorer.

Given this issue, I worked around it by querying neptune-core at startup to obtain the genesis block digest, and that works fine. However, coming from bitcoin and other blockchains I find this surprising behavior and don't feel like it should be necessary. Generally "crypto" apps can rely on genesis blocks being immutable and known to all. It's also a bit of a footgun because if i had tested only with networks alpha and testnet, I would not have caught the issue and the block-explorer would have a serious bug with respect to regtest.

To ensure I am correct on this point, I reviewed the bitcoin chainparams code. I was still a little unsure, so I asked about it on stackexchange and bitcoin devs answered that indeed regtest genesis block is fixed in code and hash will always be the same.

https://bitcoin.stackexchange.com/questions/122778/is-the-regtest-genesis-hash-always-the-same-or-not

so, for your consideration...

dan-da commented 5 months ago

If it is in the past, the automatically updated network parameters (right now only difficulty) are updated with respect to a unrealistically large and unfixed block interval

Are we doing something fundamentally different from bitcoin with the difficulty adjustment? it doesn't seem to be a problem there. hmm, I guess we are. As I recall, bitcoin does somehow keep difficulty artificially low for regtest so that new blocks can be found easily, and they have a dedicated rpc call for generating blocks.

here's a description: https://bitcointalk.org/index.php?topic=5268794.0

Neptune-Crypto / neptune-core

feat: Relativize genesis block #119