Jon pointed that i use "mitigation" to refer both to the items of this
BIP, and for the existing workarounds to make SPV verifiers safe in the
presence of 64-byte txs. This commit rephrases the latter usage.
Ariard mentioned he would like to see a test case for a 64-byte transaction spending a Taproot
output with an annex. I took the opportunity to also make the output be an OP_RETURN with a 2-byte
push, as another semi-realistic transaction.
The test vectors were initially designed to maximally simple, which led to much redundancy. That was
probably too close to one extreme on the spectrum between simplicity and efficiency.
Here we shave off 20k lines by simply representing the header chains as a tree instead of list of
lists by duplicating all common headers.
This is a batch update to the tests vectors for the limit on legacy signature-checking operations
introduced in BIP 54, following feedack received on the Bitcoin Inquisition PR and from Chris
Stewart's implementation in Bitcoin-S.
The paragraph in its entirety is already unambiguous that all signature-checking operations
*present* in the Script (as opposed to *executed*) are counted. However i received feedback that the
"potentially executed" language in the first sentence of this paragraph may be confusing. This is
because it is in theory possible to have a more accurate upper bound by analyzing the possible
spending paths and use the maximum number of signature-checking operations in either to check
against the limit.
This commit rewords the first sentence to use the word "present" to be extra-clear before even
describing how the accounting is performed in later sentences.
This introduces a set of test vectors for each of the 4 mitigations in the BIP. The sigops and
transaction size vectors were generated using the unit tests included with the Bitcoin Core
implementation of BIP54, available at https://github.com/darosior/bitcoin/tree/2509_inquisition_consensus_cleanup.
The timestamps and coinbases required mainnet blocks for maximum compatibility, and were generated
by two dedicated unit tests not included with the Bitcoin Core implementation above but available at
https://github.com/darosior/bitcoin/tree/bip54_miner.
Reading from top to bottom, the passive voice "they become BIP's author or deputy" left me wondering
how it would concretely work in practice. Link to the transferring ownership section for
clarification.
Shareholder refers to an individual or a legal entity owning a share of a company's share capital.
Since the Bitcoin system is not a company, but different actors across the industry have a stake in
its operation, i think the word "stakeholder" better conveys the intended meaning of the original
author here.
Author confused bip-0341, which defines the Taproot construction, with bip-0342, which defines the
Tapscript scripting system. Unknown key types are defined in the latter, as part of the semantics of
the CHECKSIG{VERIFY} and CHECKSIGADD opcodes.
Since the sigOpCount calculation was copied from P2SH, and P2SH
restricts the use of CHECKMULTISIG with pushed integers the reference
implementation would not take into account the number of public keys for
17 to 20 keys (not representable with an OP_N) even for P2WSH.
Therefore it fallbacks to accounting for 20 sigops in this case, which
this sentence seemed to mismatch with.
Btcd and Libbitcoin use the same calculation as in Bitcoin Core.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
Antoine Poinsot