In the "invalid output witnessScript typed key" case, the value no longer hashes to the redeemScript's P2WSH program: 65f0b3dd trimmed it to its last six bytes while fixing a short read. This restores the original 37-byte script as the value and keeps the key one byte too long — the only defect, same layout the redeemScript case already uses, same total length.
Made with my usual tools: a computer, the Internet and an LLM. The mistakes, as usual, are all mine.
@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.
Tend to NACK
The pr description is needlessly verbose and confusing. I've re-read it 5 times and do not understand what the actual problem is. What do curve points have to do with witness scripts? The keydata for a PSBT_OUT_WITNESS_SCRIPT does not contain any interpretable data, and the point of the test is to make sure that parsers are checking the length and not interpreting any data.
FWIW, per Grok the description is confusing but the fix is correct: https://grok.com/share/bGVnYWN5_3c8755f5-bf63-4673-b6cf-6942c3a71cf1.
You're right about the curve points — the keydata is filler, so nothing off-curve is reachable; my description was wrong. The real defect: since 65f0b3dd the witnessScript value no longer hashes to the redeemScript's P2WSH program. This restores the original 37-byte script as the value and keeps the key one byte too long — the same layout the redeemScript case already uses. Happy to close if that check doesn't belong here.
In the "PSBT with invalid output witnessScript typed key" case, the
value of the PSBT_OUT_WITNESS_SCRIPT record no longer hashes to the
P2WSH program in the output's redeemScript: 65f0b3dd trimmed it to its
last six bytes while fixing a short read.
Re-encode the record as `02 0100 25 <script>`: the key stays one byte
too long, which is what the case tests, and the value is the original
37-byte script again. Same total length, same layout as the "invalid
output redeemScript typed key" case.