Really don’t validate genesis block #9102

1. 
   instagibbs commented at 2:05 am on November 8, 2016: member

   A few more places where genesis blocks are being tested for validity and would pop up when tested chainparam configurations. Genesis block should be treated as a consensus rule.
2. 
   instagibbs commented at 2:15 am on November 8, 2016: member

   Moving the CheckBlock in ConnectBlock seems to cause p2p-compactblocks.py to stall out when run in batch. Perhaps seeing patterns that do not exist.
3. in src/txdb.cpp: in 6e18ae4183 outdated

   198@@ -199,7 +199,7 @@ bool CBlockTreeDB::LoadBlockIndexGuts(boost::function<CBlockIndex*(const uint256
   199                 pindexNew->nStatus        = diskindex.nStatus;
   200                 pindexNew->nTx            = diskindex.nTx;
   201 
   202-                if (!CheckProofOfWork(pindexNew->GetBlockHash(), pindexNew->nBits, Params().GetConsensus()))
   203+                if (!CheckProofOfWork(pindexNew->GetBlockHash(), pindexNew->nBits, Params().GetConsensus()) && pindexNew->GetBlockHash() != Params().GetConsensus().hashGenesisBlock)
   

   ---

   ---

   

   jtimon commented at 3:30 am on November 8, 2016:

   style nit: perhaps new line after && here?
4. 
   jtimon commented at 3:39 am on November 8, 2016: contributor

   tested ACK 6e18ae4

   EDIT: walletbackup.py doesn’t really pass locally, only when I run it individually, the failure seems to start at 50e8a9cc

   EDIT2: I would test ACK https://github.com/bitcoin/bitcoin/compare/master...jtimon:0.13-instagibbs-dontvalidategenesis though (based on e9847303 works for me)

5. jtimon approved
6. 
   laanwj commented at 10:11 am on November 8, 2016: member

   I wonder how many times we’ve purportedly fixed this.

   Can you please add a test to make sure that the genesis block is really, really not validated and to prevent this from regressing again?

7. dcousens approved
8. 
   instagibbs commented at 1:40 pm on November 8, 2016: member

   @laanwj Until we have a method of loading up our own test networks via json/whatever I’m not sure how to test this. We need to create an invalid genesis block and has it pass, right?
9. 
   jtimon commented at 1:58 pm on November 8, 2016: contributor

   @laanwj You may be remembering some of my previous attempts at doing this (like #6597 or #6230 ), but they didn’t get merged. It is true that the only way to make sure it is and remains complete is to test it though. But I’m afraid the only way to test this is from rpc and with a new chain whose genesis block is actually invalid (and not only in pow but other things like bip34). We could more easily write such a test with something like #8994 which contains this and other things to make testchains more easily.
10. fanquake added the label Validation on Nov 9, 2016
11. 
    paveljanik commented at 9:37 pm on February 22, 2017: contributor

    Needs rebase.
12. Really don't validate genesis block 10be0c5b46
13. instagibbs force-pushed on Feb 24, 2017
14. 
    instagibbs commented at 3:27 pm on February 24, 2017: member

    rebased
15. 
    jtimon commented at 7:00 pm on February 24, 2017: contributor

    As a reminder, #8994 tests this commit with all python tests except for p2p-segwit.py and p2p-compactblocks.py. @laanwj would that be sufficient testing? Is there a simpler way to test it and have tests that prevent this from breaking again than create a new regtest-like testchain whose genesis block doesn’t satisfy pow?
16. 
    instagibbs commented at 6:51 pm on May 18, 2017: member

    Closing as it needs tests, and #8994 provides those, so they should be packaged together.
17. instagibbs closed this on May 18, 2017

    ---

18. kallewoof referenced this in commit c7e5549317 on Oct 4, 2019
19. kallewoof referenced this in commit c0d1dbc833 on Oct 4, 2019
20. DrahtBot locked this on Sep 8, 2021

Contributors
instagibbs jtimon laanwj dcousens paveljanik

Labels
Validation