BIP-174: test data: a public key in the witnessScript case - #2238
Open
fametrano wants to merge 1 commit into
Open
BIP-174: test data: a public key in the witnessScript case#2238fametrano wants to merge 1 commit into
fametrano wants to merge 1 commit into
Conversation
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.
65f0b3d 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "PSBT with invalid output witnessScript typed key" case tests one
condition: a
PSBT_OUT_WITNESS_SCRIPTkey longer than the one octet thetype is. Its last record, key length included, is
Read as a stream, the witnessScript is
and
x**3 + 7is not a square mod p for that x: the pushed key is not apoint 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.
65f0b3d replaced
2bwith06to makethe value length consistent: with
2bit is 43 where 7 octets remain, anda 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 is876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65, 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.
Same length as now, same failure, and the first 222 of the 264 octets
unchanged.
bitcoin/bitcoin's
test/functional/data/rpc_psbt.jsoncarries thepre-65f0b3dd octets, byte for byte: that copy has the key and the short
read. The encoding above serves both.