Update nMinimumChainWork and defaultAssumeValid. #9779

gmaxwell commented at 7:33 PM on February 16, 2017: contributor

No description provided.

Update nMinimumChainWork and defaultAssumeValid. 3f78e460ba

petertodd commented at 7:44 PM on February 16, 2017: contributor

jtimon commented at 8:47 PM on February 16, 2017: contributor

utACK 3f78e46 for mainnet. For testnet, getblock "0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc" tells me that the minimum chain work should be 0x00000000000000000000000000000000000000000000001dcfc5dbe39283e519 instead of 0x00000000000000000000000000000000000000000000001f057509eba81aed91

MarcoFalke commented at 9:17 PM on February 16, 2017: member

@jtimon The minimum chain work is not required to match the work of the block that is assumed to be valid.

On Thu, Feb 16, 2017 at 9:47 PM, Jorge Timón notifications@github.com wrote:

utACK 3f78e46 for mainnet. For testnet, getblock "0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc" tells me that the minimum chain work should be 0x00000000000000000000000000000000000000000000001dcfc5dbe39283e519 instead of 0x00000000000000000000000000000000000000000000001f057509eba81aed91

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

jtimon commented at 9:40 PM on February 16, 2017: contributor

Right, but any reason for not having them matching? EDIT: (specially when you're updating both)

MarcoFalke commented at 9:49 PM on February 16, 2017: member

I assume the rationale is that testnet is super flaky and it is better to be conservative in what block to assume valid, as it has to be part of a valid chain to have any effect.

... In theory you could even "pre-date" the minimum chain work to the minimum chain work you expect at the earliest expected time of release.

fanquake added the label Validation on Feb 17, 2017

gmaxwell commented at 3:01 AM on February 17, 2017: contributor

@jtimon we only set the assumevalid back because the chain might reorg. But even if the chain reorgs the work will be strictly equal or better. So the chainwork should be set as far forward as possible, but assumevalid may need to be set back to avoid reorgs. (I submitted this PR only after looking to see that there was no visible fork at the bitcoin height there and checked that the block was a couple minutes old at least, otherwise I would have set it one block back-- but I still would have had chainwork at the highest point currently available)

And yes, as Marco says: we could even set minimum chain work into the future (except for the fact that doing so might confuse testing!)

sipa added this to the milestone 0.14.0 on Feb 17, 2017

laanwj merged this on Feb 17, 2017

laanwj closed this on Feb 17, 2017

laanwj referenced this in commit 3c02b95740 on Feb 17, 2017

MarcoFalke commented at 1:11 AM on February 18, 2017: member

in src/chainparams.cpp:None in 3f78e460ba

  96 | @@ -97,10 +97,10 @@ class CMainParams : public CChainParams {
  97 |          consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1510704000; // November 15th, 2017.
  98 |  
  99 |          // The best chain should have at least this much work.
 100 | -        consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000002cb971dd56d1c583c20f90");
 101 | +        consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000003f94d1ad391682fe038bf5");
 102 |  
 103 |          // By default assume that the signatures in ancestors of this block are valid.
 104 | -        consensus.defaultAssumeValid = uint256S("0x0000000000000000030abc968e1bd635736e880b946085c93152969b9a81a6e2"); //447235
 105 | +        consensus.defaultAssumeValid = uint256S("0x00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90"); //453354

sdaftuar commented at 7:52 PM on February 27, 2017:

ACK 0x00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90

in src/chainparams.cpp:None in 3f78e460ba

 200 | @@ -201,10 +201,10 @@ class CTestNetParams : public CChainParams {
 201 |          consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1493596800; // May 1st 2017
 202 |  
 203 |          // The best chain should have at least this much work.
 204 | -        consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000000000198b4def2baa9338d6");
 205 | +        consensus.nMinimumChainWork = uint256S("0x00000000000000000000000000000000000000000000001f057509eba81aed91");
 206 |  
 207 |          // By default assume that the signatures in ancestors of this block are valid.
 208 | -        consensus.defaultAssumeValid = uint256S("0x000000000871ee6842d3648317ccc8a435eb8cc3c2429aee94faff9ba26b05a0"); //1043841
 209 | +        consensus.defaultAssumeValid = uint256S("0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc"); //1079274

sdaftuar commented at 7:52 PM on February 27, 2017:

ACK 0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc

sdaftuar commented at 7:52 PM on February 27, 2017: member

post-merge ACK

DrahtBot locked this on Sep 8, 2021