SoftForks Unit
This PR gathers the various soft fork mechanisms into one place making it more orderly. As a positive side effect, it will also make the VersionBits implementation simpler.
This PR depends on #6774
concept ACK, once over utACK
Can you put softforks.{cpp,h} under the consensus/ directory?
Nice! utACK.
Concept ACK
Long-term isnt the goal to just switch enforcement of most softforks to blockheight/timestamp and then use versionbits globally? (I believe most things were rolled out via a IsSuperMajority-like system, and then the code was just simplified later by replacing the checks with what-the-switchover-date-was checks).
@TheBlueMatt indeed - that's exactly what will end up happening once things are buried deeply enough.
Mmm, ok, well I hadnt really read the code to begin with and I figured you were jumping the gun, but the code does simplify things on its own, so concept ack that.
I checked consensus is not affected by spinning up a new node and syncing from scratch. The node synced to the correct tip @ block 377385, 0000000000000000056d10c5f1cc9961ce2476da818a2fb4dd54ca3bcfb99a8d
ACK
1719 | - // two in the chain that violate it. This prevents exploiting the issue against nodes during their 1720 | - // initial block download. 1721 | - bool fEnforceBIP30 = (!pindex->phashBlock) || // Enforce on CreateNewBlock invocations which don't have a hash. 1722 | - !((pindex->nHeight==91842 && pindex->GetBlockHash() == uint256S("0x00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec")) || 1723 | - (pindex->nHeight==91880 && pindex->GetBlockHash() == uint256S("0x00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721"))); 1724 | + // For soft fork details, look in consensus/softforks.cpp
Are these "look in consensus/softfork.cpp" comments really necessary or useful?
I liked '''Consensus::GetFlags''' see https://github.com/jtimon/bitcoin/commit/9ba7d0641019d7f6c08f7b15ce3a2bd2e5e8a4ac even more, but this is definitely a step in the right direction...
re-ACK
18 | + BIP34, 19 | + BIP42, 20 | + BIP62, 21 | + BIP65, 22 | + BIP66, 23 | + BIP68,
In my optinion there's no need to include future softforks/hardforks here (perhaps with the exception of BIP65 which is already merged as a policy rule), they can add themselves in their own PRs if they're merged after this.
Agreed
Sorry, I meant to say the following here: #6774 (comment)
rebase or close for now?
I think 7575 supersedes this.
@btcdrak well, it would need to be greatly rewritten after #7575, but what I think is the general idea it's still possible, see https://github.com/jtimon/bitcoin/commit/dd446faf641350fb469865fc3586d1e088bdfb00 and https://github.com/jtimon/bitcoin/commit/032182336d84a420f33be3ab7d204c9b5f8ae8cf But yeah, probably a new PR would be a better idea if it's going to be rewritten.
Needs rebase/new pull if still relevant
Closing for now