BIP-174: test data: fix off-curve pubkey 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 should fail on the key length — a PSBT_OUT_WITNESS_SCRIPT key longer than one octet — but as written it can also fail on an off-curve pubkey: the witnessScript pushes 03b7ce…9d06d5…, and x**3 + 7 is not a square mod p for that x. An implementation that validates pushed keys but never checks the key length rejects the case anyway, for the wrong reason, and the missing check goes undetected.

The off-curve key is an artifact: 65f0b3dd changed one octet of it (2b → 06) to fix a short read on the value length, but the case's hashes (P2WSH 876bad83…, P2SH b921b1ba…) still commit to the script with 2b.

This re-encodes the record as 02 0100 25 <script with 2b> — the extra octet in the key, the whole on-curve script in the value, as the "invalid output redeemScript typed key" case already does. Same total length, same intended failure, hashes match again; bitcoin/bitcoin's rpc_psbt.json still carries the pre-65f0b3dd octets (a short read), so this encoding serves both.
fametrano commented at 9:24 AM on September 7, 2026: contributor

@achow101 as BIP174's author, could you take a look? In short: the "invalid output witnessScript typed key" vector is meant to fail on the key length alone, but the pushed key in its witnessScript is not a point on secp256k1, so an implementation that validates the key and skips the length check rejects the case for the wrong reason and the missing check goes unnoticed. This swaps in a valid point; nothing else changes and CI is green.
fametrano renamed this:
~~BIP-174: test data: a public key in the witnessScript case~~
BIP-174: test data: fix off-curve pubkey in the witnessScript case
on Sep 11, 2026
fametrano renamed this:
~~BIP-174: test data: fix off-curve pubkey in the witnessScript case~~
BIP-174: test data: the witnessScript case should fail on the key length, can fail on an off-curve pubkey
on Sep 11, 2026
fametrano renamed this:
~~BIP-174: test data: the witnessScript case should fail on the key length, can fail on an off-curve pubkey~~
BIP-174: test data: fix off-curve pubkey in the witnessScript case
on Sep 11, 2026

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.

d389ceb6c4

fametrano force-pushed on Sep 12, 2026

Contributors

fametrano