BIP-174: test data: a public key in the witnessScript case #2238

pull fametrano wants to merge 1 commits into bitcoin:master from fametrano:bip174-witnessscript-vector-pubkey changing 1 files +2 −2

fametrano commented at 10:46 PM on August 5, 2026: contributor
The "PSBT with invalid output witnessScript typed key" case tests one condition: a PSBT_OUT_WITNESS_SCRIPT key longer than the one octet the type is. Its last record, key length included, is
```
21 010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d 06 d57f8a8751ae
```
Read as a stream, the witnessScript is
```
OP_1 <03b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a87> OP_1 OP_CHECKMULTISIG
```
and x**3 + 7 is not a square mod p for that x: the pushed key is not a point of secp256k1.

An implementation that checks the pushed key but not the key length refuses the case for the wrong reason and the missing check goes undetected.

65f0b3dd62ecc55e43436173c5f84e893809d0fa replaced 2b with 06 to make the value length consistent: with 2b it is 43 where 7 octets remain, and a reader that takes the whole key-value pair before judging the key hits a short read. That octet is the 29th of the pushed key.

The case commits to the key with 2b. sha256 of that script is 876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65, the P2WSH the output's redeemScript pushes, and hash160 of that redeemScript is b921b1ba6f722e4bfa83b6557a3139986a42ec83, the P2SH scriptPubKey of the unsigned transaction's second output. The script as it reads today hashes to bcea4f011e49b37595c2c24fd4b39077670a5d3a32dd47ed928d4e0dfbb21dc8, which nothing in the case commits to. Another point in its place would mean recomputing both hashes and the unsigned transaction; keeping it means moving the value length off it.

The record below does that, carrying the extra octet in the key and the whole script in the value, as the "invalid output redeemScript typed key" case does.
```
02 0100 25 512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae
```
Same length as now, same failure, and the first 222 of the 264 octets unchanged.

bitcoin/bitcoin's test/functional/data/rpc_psbt.json carries the pre-65f0b3dd octets, byte for byte: that copy has the key and the short read. The encoding above serves both.

BIP-174: test data: a public key in the witnessScript case

The "PSBT with invalid output witnessScript typed key" case tests one
condition: a PSBT_OUT_WITNESS_SCRIPT key longer than the one octet the
type is. Its last record, key length included, is

    21 010025512103b7ce...51309d 06 d57f8a8751ae

Read as a stream, the witnessScript is

    OP_1 <03b7ce23...51309d06d57f8a87> OP_1 OP_CHECKMULTISIG

and x^3 + 7 is not a square mod p for that x: the pushed key is not a
point of secp256k1.

An implementation that checks the pushed key but not the key length
refuses the case for the wrong reason and the missing check goes
undetected.

65f0b3dd62ec replaced 2b with 06 to make the value length consistent:
with 2b it is 43 where 7 octets remain, and a reader that takes the
whole key-value pair before judging the key hits a short read. That
octet is the 29th of the pushed key.

The case commits to the key with 2b. sha256 of that script is
876bad83...2b278a65, the P2WSH the output's redeemScript pushes, and
hash160 of that redeemScript is b921b1ba...6a42ec83, the P2SH
scriptPubKey of the unsigned transaction's second output. The script as
it reads today hashes to bcea4f01...fbb21dc8, which nothing in the case
commits to. Another point in its place would mean recomputing both
hashes and the unsigned transaction; keeping it means moving the value
length off it.

The record below does that, carrying the extra octet in the key and the
whole script in the value, as the "invalid output redeemScript typed
key" case does.

    02 0100 25 512103b7ce...2bd57f8a8751ae

Same length as now, same failure, and the first 222 of the 264 octets
unchanged.

e0d51f1035

Contributors

fametrano