BIP-174: test data: make the witnessScript in the invalid-key case match its P2WSH hash

[fametrano]

In the "invalid output witnessScript typed key" case, the value no longer hashes to the redeemScript's P2WSH program: 65f0b3d 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.

[fametrano]

@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.

[achow101]

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.

[jonatack]

FWIW, per Grok the description is confusing but the fix is correct: https://grok.com/share/bGVnYWN5_3c8755f5-bf63-4673-b6cf-6942c3a71cf1.

[fametrano]

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 65f0b3d 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.