0

Recently, I happened to see in a codebase something like the following snippet to convert a standard transaction into a psbt format:

txHex = "01000000038caba88b36e86b253de1c22574205ad7d46598a87349b2e7f364d244246b66820000000000ffffffff8d4cefc5b67a8ae0e4c6b8fd7ee259943c29b46471c4f31a5252422177fa20770100000000ffffffff68bc5046732a7e7e57b8f0abd6f94c63f7153738cb39525d497ce1cd765e35230100000000ffffffff02404b4c00000000001976a9148eccac781789b66751f19c3a58f36526a201786488ac00093d00000000001976a9148eb446f809f526fb37059a32cf8255c4cb43d2da88ac00000000"
psbt = "70736274ff0100c9" + txHex + "000000000000"

Is this correct? One thing I understood after reading bip174 is that the last byte of the prefix should not be hardcoded because it contains the lenght of the transaction, but I have no clue about the suffix

0

The "suffix" is not a fixed suffix. The number of 00 bytes needs to match the number of inputs and outputs of the transaction. Those bytes are the terminators for the key-value maps for each input and output. The automatic converter does not fill in those maps, but an empty map will still have its null terminator. So the number of empty maps (and thus the number of null terminators) will change depending on the number of inputs and outputs in your transaction.

Also, those bytes will change as the PSBT gets filled with information. It is not a fixed suffix. So as the extra data for signing for each input and output gets filled, the "suffix" of your PSBT will change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.