Hi, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 5, 2018 12:20 PM, William Casarin <j...@jb55.com> wrote: > > > 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. I don't think this is really a problem. Almost all roles have to deserialize the unsigned tx anyways before they can do anything. The only role that doesn't is a simple combiner (a combiner that does sanity checks would still have to deserialize the unsigned tx), and even then it doesn't matter. It just shoves key value pairs together and doesn't need to know whether the map is for an input or for an output. > > 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. If a combiner writes the wrong number of key-value maps, then it would simply be invalid to the next person that receives the PSBT. It would not deserialize properly because the key value pairs would have incorrect values for their types. Not deserializing properly means that the PSBT is simply invalid. The same numerical types might be shared, but their meanings are different between the input and output types. 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 have added that to the BIP. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On July 5, 2018 10:23 AM, Jason Les <jason...@gmail.com> wrote: > Has there been any thought to standardizing file names used when creating > .psbt files? Maybe something that gives some reliability of being collision > resistant and descriptive. For example: > > [8 char trim of hash of unsigned tx]+[Role that created file (Ex: Signer)]+[4 > char trim of hash of data unique to that role (Ex: partial sig)] > > It may be useful to especially the combiner to have some idea of what files > they have. > > -Jason Les I haven't considered this, but I'm not sure if it is really useful. I don't think it is really necessary for any role to know who created the PSBT. If it did, this information would generally come out-of-band anyways as someone has to give the PSBT to that person. Andrew _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
