bip-0375: say the version byte belongs to the identifier, not to the field - #2257
Open
fametrano wants to merge 1 commit into
Open
bip-0375: say the version byte belongs to the identifier, not to the field#2257fametrano wants to merge 1 commit into
fametrano wants to merge 1 commit into
Conversation
…field "The PSBT_OUT_SP_V0_INFO should be serialized as a zero byte for the version, followed by the 33 bytes of the scan key and then 33 bytes for the spend key" names the field, and the field is 66 bytes: its table entry is "<33 byte scan key> <33 byte spend key>", the test vectors carry 66, and the validator refuses anything else. The sentence is in the Unique Identification section and was added with it, so what it describes is the output script that stands in for a silent payment output when building the unsigned transaction that identifies the psbt -- 67 bytes there, and nothing about the field. Read as the field's own serialization it contradicts the table, which is how it first read here. Only the wording changes.
Member
|
@fametrano Thank you for your contribution. Out of personal curiosity, what AI did you use to make 228 GitHub contributions (so far) today? The PR description is a little hard to grok, can you summarize more concisely in your own words, please? |
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
2 participants
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.
One sentence, in the Unique Identification section:
It names the field, and the field is 66 bytes: its table entry is
<33 byte scan key> <33 byte spend key>,bip375_test_vectors.jsoncarries66, and
validator/validate_psbt.pyrefuses anything else —invalid[1]reports "Output 0 SP_V0_INFO has wrong length (65 bytes, expected 66)".
Read in its section the sentence is not about the field but about the output
script that stands in for a silent payment output when building the unsigned
transaction used for unique identification, where 67 bytes contradicts
nothing. That is also where it came from:
d29e2f8added it together withthe unique-identification paragraph above it.
Both readings are available to someone reading the sentence alone, and one of
them contradicts three other artefacts. This picks the one that does not,
without changing anything normative.
No changelog entry or version bump: nothing about the format changes, and
leaving them out keeps this from conflicting with
#2207 or
#2256, both of which touch the
changelog. Glad to add both if you would rather have them.
scripts/link-format-chk.sh,scripts/buildtable.pl,scripts/diffcheck.shandtypospass locally.Noticed while implementing BIP375 in btclib, which serializes the version
byte in the identifier and not in the field:
btclib-org/btclib#768