-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSET: Various fixes #1121
PSET: Various fixes #1121
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code review ACK 32c3a98. Double checked that rust-elements parser and parser that allen implemnted https://tools.blockstream.com/psbt parses the new serialization correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 32c3a98
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK b4378ec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 32ac36a
A single 0x00 byte indicates a zero length field; we must skip parsing that field otherwise the length will be expected to be read again for the vector that is passed in to revieve the value. This allows PSBT_ELEMENTS_GLOBAL_SCALAR to be parsed when it is serialized according to the spec, i.e. both of the following cases will correctly parse to the same representation: $cli decodepsbt 'cHNldP8B+wQCAAAAAQIEAgAAAAEEAQABBQEAJ/wEcHNldAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fIAEAAA==' and $cli decodepsbt 'cHNldP8B+wQCAAAAAQIEAgAAAAEEAQABBQEAJ/wEcHNldAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4fIAAA' PSBT_ELEMENTS_GLOBAL_SCALAR is the only PSBT/PSET field that contains key data but no value data and so is the only field that currently hits this special case.
Note the re-parsing of the correct serialization is covered by the existing PSBT tests which process PSBTs containing scalars.
While the order of fields is not explicit in the PSBT/PSET specifications, third parties need to be able to support both with a single implementation. Keeping the PSBT fields in the same order makes this significantly easier.
ASSET_COMMITMENT and ASSET were in the wrong order, which prevents simply iterating the constants in simple parsers/writers.
As for outputs. ISSUANCE_VALUE_COMMITMENT and ISSUANCE_VALUE were misordered.
This makes global handling forwards-compatible when new fields are added, and un-breaks any PSET implementations that serialize PSBT_ELEMENTS_GLOBAL_TX_MODIFIABLE (which Elements does not yet implement).
This allows these test cases to be re-used by alternate implementations for round-trip serialization testing.
I found this useful for for creating test cases and checking validity. In the event that alternative implementations do not aim for exact serilization compatibility, this RPC can be used to validate and re-serialize their output for testing.
32ac36a
to
3be6e80
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 3be6e80
…lements 22rc3.
parsepsbt
rpc for testingFixes #1065