Merge pull request #2122 from darosior/2603_bip54_improvements

BIP 54 test vectors improvements following review in Inquisition

Author: murchandamus

bip-0054.md

@@ -64,7 +64,7 @@ Given a block at height `N`:
   or equal to the value of the timestamp of the block at height `N-2015` (T<sub>N</sub> &ge;
   T<sub>N−2015</sub>).
 
-A limit is set on the number of potentially executed signature operations in validating a
+A limit is set on the number of signature operations present in the scripts used to validate a
 transaction. It applies to all transactions in the block except the coinbase transaction[^1]. For
 each input in the transaction, count the number of `CHECKSIG` and `CHECKMULTISIG` in the input
 scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total summed
@@ -123,7 +123,10 @@ validation will need to be re-activated from block 1,983,702. A simple way to pr
 mandate that future coinbase transactions vary from coinbase transactions before [bip-0034][BIP34]
 activation. There are multiple ways of achieving this, but setting and enforcing the timelock for
 the coinbase transaction makes it so all coinbase transactions past Consensus Cleanup activation
-could not have been valid before this height and therefore cannot be a duplicate[^11].
+could not have been valid before this height and therefore cannot be a duplicate[^11]. This
+simplifies both reasoning and client implementation, since the [bip-0030][BIP30] check can be
+skipped entirely past Consensus Cleanup activation, regardless of the [bip-0034][BIP34] activation
+status[^12].
 
 ## Backward compatibility
 
@@ -218,6 +221,10 @@ bip-0034 height commitment and the corresponding future block height.
 coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent
 for any implementation which enforces `nLockTime` from the genesis block, which is the behaviour
 notably of Bitcoin Core but also of all other implementations the authors are aware of.
+[^12]: For instance Bitcoin Core only disables [bip-0030][BIP30] validation for a specific chain
+where [bip-0034][BIP34] violations have been manually inspected (see [here][Core validation.cpp
+BIP34]). Without the guarantee given by enforcing the timelock on coinbase transactions, this would
+have to be perpetuated for the Consensus Cleanup.
 
 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
 [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki
@@ -242,3 +249,4 @@ notably of Bitcoin Core but also of all other implementations the authors are aw
 [Core 29.0]: https://bitcoincore.org/en/releases/29.0
 [inquisition-implem]: https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup
 [Core 30.0]: https://bitcoincore.org/en/releases/30.0
+[Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459

bip-0054/test_vectors/coinbases.json

@@ -76,4 +76,5 @@
         "valid": false,
         "comment": "Block at height 4 with coinbase's nLockTime set to block's nTime minus 1 and maximum non-final nSequence."
     }
-]
+]
+