William Casarin [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-05 📝 Original message:I have another concern ...
📅 Original date posted:2018-07-05
📝 Original message:I have another concern with the format. (my original bip comment for some context: [1])
It looks like the one of the reasons I was confused is because you can
only parse the format properly by first deserializing the transaction.
Since there is no "length" field for the key-value map arrays, you must
count the number of transaction input/outputs, and use that as the
number of kv maps to parse.
This is pretty brittle, because now if a Combiner writes the wrong
number of key-value maps that don't align with the number of inputs and
outputs in the transaction, then the psbt will not be able to be
deserialized properly, but is still a valid PSBT. It can't even detect
these situations, because the input and output types share the same enum
values. I don't see anywhere that says the number of key value maps MUST
match the number of inputs/outputs, perhaps it's implied?
I think I think we should either make this explicit in the BIP, add an
array length prefix, or make all (global/input/output) types share the
same enum.
Cheers,
William
[1] https://github.com/bitcoin/bips/pull/694#issuecomment-402812041
📝 Original message:I have another concern with the format. (my original bip comment for some context: [1])
It looks like the one of the reasons I was confused is because you can
only parse the format properly by first deserializing the transaction.
Since there is no "length" field for the key-value map arrays, you must
count the number of transaction input/outputs, and use that as the
number of kv maps to parse.
This is pretty brittle, because now if a Combiner writes the wrong
number of key-value maps that don't align with the number of inputs and
outputs in the transaction, then the psbt will not be able to be
deserialized properly, but is still a valid PSBT. It can't even detect
these situations, because the input and output types share the same enum
values. I don't see anywhere that says the number of key value maps MUST
match the number of inputs/outputs, perhaps it's implied?
I think I think we should either make this explicit in the BIP, add an
array length prefix, or make all (global/input/output) types share the
same enum.
Cheers,
William
[1] https://github.com/bitcoin/bips/pull/694#issuecomment-402812041