[jasonsopko]

What

Counts the pushes in a multisig script that cannot be a key as data under -rejectfakemultisig, and takes Kyle's later fix from knots#422 for a tapscript k from 128, with Chris's two one-line casts from privkeyio/bitcoin#2. For #4.

Why

In a 1-of-n OP_CHECKMULTISIG with the signing key last, consensus never examines the other key slots, so they take any push (#4). A 37 or 100 byte push there counted as neither a key nor data: 14 slots carry 1,400 bytes per input past the filter.

The rule, in a script that runs OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY:

• Every push of 6 or more bytes that cannot be a key counts as data in full, outside the allowance of 10 keys. A push is left out when it is a digest a hash lock compares (the size the hash opcode before it outputs, followed by OP_EQUAL or OP_EQUALVERIFY), or when the drop and envelope rules count it already.
• A push of 5 bytes or less counts too when another push follows it, with nothing between but OP_NOP, OP_CODESEPARATOR or an upgradable NOP. A script reads a number with the opcode after it, and a key count, the one number with keys pushed after it, is left alone. Without this, nine chained 1-of-10s with bare 5 byte slots carry 405 bytes in one input.
• In a witness script a 65 byte push counts too: segwit policy refuses an uncompressed key wherever it checks one, and ten such slots would otherwise carry 650 bytes inside the allowance.

Unlike the slot rule #4 suggests, none of this needs a literal key count, so a computed count and no-ops between the slots are covered too.

knots#422 has moved past the commit Plumb merges. Kyle's eea2467 is here, its code as it is there and its tests next to Plumb's older ones: a tapscript multi_a k from 128 is written 80 00, and Plumb read that as not minimal and counted the keys. Chris's 06a878f38a and d6ec42b98f from privkeyio/bitcoin#2 follow it under his name: a cast MSVC needs in MultiACount, and one in a test helper that the k test needs past 255 keys. knots#422 has both inside its own commits.

How I tested

• Unit tests for the -rejectfakemultisig ignores key slots whose push is not 33 or 65 bytes #4 case, slots of 100, 5 and 1 bytes, a computed key count, OP_NOP and OP_CODESEPARATOR between slots, 32 byte slots, OP_CHECKMULTISIGVERIFY, OP_EQUAL with no hash opcode before it, 65 byte slots in a witness script and short pushes in a dropped run, and for what real multisig scripts carry besides keys: hash locks, an OP_FALSE OP_IF tag, dropped pushes, timelock numbers, a key count above 16, uncompressed keys in a redeem script. The functional test spends the -rejectfakemultisig ignores key slots whose push is not 33 or 65 bytes #4 case and a 1-of-20 with 5 byte slots on regtest: each is refused with the filter on, and the 100 byte case is accepted with -rejectfakemultisig=0.
• Merged onto plumb7 (tree 7ad0689e2d): ctest 146 of 146 and the full functional suite pass.
• Every transaction from 961640 to 977870 with an input whose P2SH or P2WSH script runs CHECKMULTISIG, 179,183 of them, through cesspool's plumb-check harness built from this tree and from plumb7: the same verdict and data count for every one.
• P2P relay on regtest, plumb7 and this tree built with the same flags, zero-fee spends from one inbound peer, per transaction:

spend	this tree	plumb7
1-of-15, 14 slots of 37 bytes	0.09 ms	0.11 ms
1-of-16, 15 slots of 100 bytes	0.09 ms	0.11 ms
213 pushes of 6 bytes	0.11 ms	0.16 ms
1-of-20, 19 slots of 5 bytes	0.08 ms	0.11 ms
249 pushes of 5 bytes	0.11 ms	0.18 ms
1,000 inputs, one 37 byte slot each	2.68 ms	4.02 ms
900 plain 2-of-3 inputs	4.85 ms	4.35 ms

This tree refuses the first six at the data carrier check, before the fee check plumb7 refuses them at. The peer stayed connected throughout, and the median getblockcount took under 1 ms. Over four runs of this same bitcoind today the plain row read 4.35 to 4.85 ms, and plumb7's 4.19 to 4.36 ms.

GitHub will show a conflict in test/functional/mempool_datacarrier.py against 29.x-plumb. The test merge kept both blocks. It also added /*dead_branches=*/true to the five script_tests calls this PR adds that pass bare_envelopes, since plumb7's DatacarrierBytesStr takes dead_branches first; GitHub does not flag those.

Risk and rollback

Policy only, on by default with the filter. A real multisig spend now has bytes counted toward -datacarriersize if it holds a push of 6 or more bytes that cannot be a key, no hash lock digest and not counted by the drop or envelope rules, or a short push that another push follows. None since the fork has either, and no multisig witness script since the fork has a 65 byte push. With -rejectdeadbranches too, a push in a dead branch of a multisig script counts under both rules: 37 bytes there count as 37 + 41. At the defaults that changes nothing, because the dead-branch bytes alone get the input refused (txn-datacarrier-nonstandard); it matters only with -acceptnonstddatacarrier=1. -rejectfakemultisig=0 turns the whole filter off, and reverting the merge backs this out.

Still unsure about

• A hash lock digest still counts as nothing, and a script cannot tell a real digest from data. In the key slots that is -rejectfakemultisig ignores key slots whose push is not 33 or 65 bytes #4 again at 32 bytes of data per 36 of script: a 1-of-15 whose 14 slots are OP_DUP OP_SHA256 <32 bytes> OP_EQUAL carries 448 bytes, and a 1-of-20 and a 1-of-18 in one input carry 1,152, accepted on regtest. A cap on digests per script, as on keys, would bound it: no multisig script since the fork has more than one digest before OP_EQUAL or 11 before OP_EQUALVERIFY.
• The allowance itself still lets ten unproven 33 byte slots carry 330 bytes per script, by design of knots#422. In a redeem script, where an uncompressed key is still valid, seven 65 byte slots carry 455 bytes the same way.
• Some data pushes still count as nothing. Outside multisig scripts, <37 bytes> <key> OP_NIP OP_CHECKSIG and <37 bytes> <key> OP_SWAP OP_DROP OP_CHECKSIG do. Inside one, so does a push of 5 bytes or less with any opcode but a push or a no-op after it: a 1-of-15 whose 14 slots are <5 bytes> OP_CHECKSEQUENCEVERIFY or <5 bytes> OP_SIZE OP_DROP is accepted on regtest. That costs 7 or 8 bytes of script for 5 of data, where a bare slot costs 6.
• A multisig in the OP_ELSE half of OP_FALSE OP_IF ... OP_ELSE ... OP_ENDIF is skipped as part of the envelope: 15 slots of 100 bytes there count 2 bytes. At the defaults those 2 bytes get the input refused (txn-datacarrier-nonstandard). With -acceptnonstddatacarrier=1 they are held to -datacarriersize instead, so it passes.