It’s been on the agenda for some time to disable POW check for genesis block. As signet blocks will not have valid proof of work for the genesis block, it makes sense to do this change unconditionally.
This is a part of #16411 but as it is a minor consensus tweak, it probably deserves its own PR.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
3033@@ -3031,10 +3034,13 @@ bool CheckBlock(const CBlock& block, CValidationState& state, const Consensus::P
3034 if (block.fChecked)
3035 return true;
3036
3037- // Check that the header is valid (particularly PoW). This is mostly
3038- // redundant with the call in AcceptBlockHeader.
3039- if (!CheckBlockHeader(block, state, consensusParams, fCheckPOW))
3040- return false;
3041+ // We skip POW checks for genesis block
3042+ if (block.GetHash() != consensusParams.hashGenesisBlock) {
CheckBlockHeader only checks PoW at the moment).
CheckBlockHeader could check if it’s the genesis block and skip all checks. The comment here could say: “Check that the header is valid (particularly PoW, and except for the genesis block)”
273@@ -274,7 +274,7 @@ bool CBlockTreeDB::LoadBlockIndexGuts(const Consensus::Params& consensusParams,
274 pindexNew->nStatus = diskindex.nStatus;
275 pindexNew->nTx = diskindex.nTx;
276
277- if (!CheckProofOfWork(pindexNew->GetBlockHash(), pindexNew->nBits, consensusParams))
278+ if (pindexNew->GetBlockHash() != consensusParams.hashGenesisBlock && !CheckProofOfWork(pindexNew->GetBlockHash(), pindexNew->nBits, consensusParams))
It's been on the agenda for some time to disable POW check for genesis block. As signet blocks will not have valid proof of work for the genesis block, it makes sense to do this change unconditionally.
@MarcoFalke They can, but in order to set up a new signet network, you would need to actually sign and mine the genesis block. There is no readily available tool to do that, but such a tool could be created. It would complicate the initial setup process.
To clarify, this becomes a bit of a chicken and egg problem: without a signet network you can’t sign blocks and without a signed genesis block you can’t startup a new signet network.
util_signet binary or exposed via RPC than to change the consensus rules. I’d argue that this wouldn’t complicate the initial setup process.
Anyone may participate in peer review which is expressed by comments in the pull request. see CONTRIBUTING.md
@Relaxo143 You being a core dev or not is completely irrelevant. The only thing that matters is the content of what you are saying. We regularly have non-developers chime in on developer matters because these things often blend together.
That being said, my proposal is to remove the proof of work check for the genesis block, because this will otherwise cause problems when a feature is added later. Your comment does not at all address this point, which makes it of limited value, I’m afraid.
It looks like I may be moving towards not touching the proof of work checks and finding some way to grind the genesis block for signet, though, so this change will probably not go through. I just have to figure out a good way to do that.
It looks like I may be moving towards not touching the proof of work checks and finding some way to grind the genesis block for signet, though, so this change will probably not go through.
I have a light preference for that as well, if only to kick this can down the road.
Repeating my inline comment, since that might get burried: the discussion in #9102 suggests - I haven’t thought about it deeply - that we should not verify the genesis block at all, and any existing check - including a PoW check - is a regression. But sometimes leaving a regression alone is better than fixing it (devil you know).
@Relaxo143 You being a core dev or not is completely irrelevant. The only thing that matters is the content of what you are saying. We regularly have non-developers chime in on developer matters because these things often blend together.
That being said, my proposal is to remove the proof of work check for the genesis block, because this will otherwise cause problems when a feature is added later. Your comment does not at all address this point, which makes it of limited value, I’m afraid.
It looks like I may be moving towards not touching the proof of work checks and finding some way to grind the genesis block for signet, though, so this change will probably not go through. I just have to figure out a good way to do that.
What feature are you talking about exactly? Does it have to do with signet? If yes, then you are right - I did not address that because I don’t know anything about signet. That being said, maybe the change should only be applied to node configs who use signet and not to default nodes who run on mainnet?
Sorry for the necromancy, but I missed it at the time. I want to extend on some points brought up in #16411 (comment) and I don’t want that PR to re-hash the topic one more time.
Let’s go through some of the objections this or similar proposals, had:
#9102 (comment) tldr: it doesn’t have tests But now it is tested in #8994 , or a modified #16411 can also test it
I’d prefer to write a simple cpp while loop that is compiled into util_signet binary or exposed via RPC than to change the consensus rules. I’d argue that this wouldn’t complicate the initial setup process.
But now we can see it does. Only replicating the mining_signet test with say a 2 of 2 challenge would require the write tester to mine a genesis block. And we could save some code and not use the signet_nonce field, see: https://github.com/kallewoof/bitcoin/commit/010cca031dfb890f92ff78c3bf6a45326ae38edf
In the case of #8994 , having to mine each genesis block makes the new feature much less usable and makes the fact of hashing the chain name counterproductive (since a new hash will mean having to mine a genesis block again).
If I missed any other objection, please reiterate it. Sorry for the rant.