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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
