Hello,
Here's my take on Litecoin and derivatives of the Bitcoin 0.16 branch (or really anything newer than the 0.13 branch).
The part I have the most concern with in the 16.3 code starts here:
https://github.com/bitcoin/bitcoin/blob/49e34e288005a5b144a642e197b628396f5a0765/src/chainparams.cpp#L80-L83consensus.BIP34Height = 227931;
consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
consensus.BIP65Height = 388381; // 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0
consensus.BIP66Height = 363725; // 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931
The way I understand it, consensus.BIP34Height, consensus.BIP34Hash, consensus.BIP65Height and consensus.BIP66Height indicate where in the blockchain you may find the new features having been activated through the IsSuperMajority() method.
In other words, IsSuperMajority() evaluates the criteria for when the soft-forks became active.
Prior to the 0.14 branch, consensus.BIP65Height and consensus.BIP66Height did not even occur in code and the IsSuperMajority() method is how the wallet knew to enforce new protocol.
Right now, we are producing version 2 blocks. Here is an example getblock call from the RPC.
{
"hash" : "4897b09eacd83654797e02b2d4b150db1c609dcbfe87c65657624aff33fd597b",
"confirmations" : 1,
"size" : 189,
"height" : 1317286,
"version" : 2,
"merkleroot" : "2981da99a400e59a43f8b65f18ce9167d2755d840c616e87836b99a62176c172",
"tx" : [
"2981da99a400e59a43f8b65f18ce9167d2755d840c616e87836b99a62176c172"
],
"time" : 1541303715,
"nonce" : 469045,
"bits" : "1e0fffff",
"difficulty" : 0.00024414,
"previousblockhash" : "aaab82bf6e31a42bfe3e8cd8885b9a412b9cd1b0b8c770efcd07e8a615caebc9"
}
The way IsSuperMajority() works is that once a percentage threshold of blocks with the newer version number have been added to the chain; then BIP34, BIP66 and BIP65 would become active.
Here is the code from src/main.cpp for reference.
// Enforce block.nVersion=2 rule that the coinbase starts with serialized block height
// if 750 of the last 1,000 blocks are version 2 or greater (51/100 if testnet):
if (block.nVersion >= 2 && IsSuperMajority(2, pindexPrev, consensusParams.nMajorityEnforceBlockUpgrade, consensusParams))
{
CScript expect = CScript() << nHeight;
if (block.vtx[0].vin[0].scriptSig.size() < expect.size() ||
!std::equal(expect.begin(), expect.end(), block.vtx[0].vin[0].scriptSig.begin())) {
return state.DoS(100, false, REJECT_INVALID, "bad-cb-height", false, "block height mismatch in coinbase");
}
}
// Start enforcing the DERSIG (BIP66) rules, for block.nVersion=3 blocks,
// when 75% of the network has upgraded:
if (block.nVersion >= 3 && IsSuperMajority(3, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {
flags |= SCRIPT_VERIFY_DERSIG;
}
// Start enforcing CHECKLOCKTIMEVERIFY, (BIP65) for block.nVersion=4
// blocks, when 75% of the network has upgraded:
if (block.nVersion >= 4 && IsSuperMajority(4, pindex->pprev, chainparams.GetConsensus().nMajorityEnforceBlockUpgrade, chainparams.GetConsensus())) {
flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;
}
Then later in code, if the block header doesn't contain the required version we see the blocks are rejected.
// Reject outdated version blocks when 95% (75% on testnet) of the network has upgraded:
for (int32_t version = 2; version < 5; ++version) // check for version 2, 3 and 4 upgrades
if (block.nVersion < version && IsSuperMajority(version, pindexPrev, consensusParams.nMajorityRejectBlockOutdated, consensusParams))
return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", version - 1),
strprintf("rejected nVersion=0x%08x block", version - 1));
More simply, unless some other code is used to create block versions greater than 2, it would appear we could expect blocks to be rejected after any arbitrary hard-coded heights in src/chainparams.cpp.
I don't know whether my concerns are well founded.
I suspect since consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime will lead to a block version greater than 2 being created that perhaps whatever height you are hard-coding into src/chainparams.cpp should be far enough into the future that it will occur well after consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime starts producing blocks.
Best Regards,
-Chicago