Achow101 [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-06 📝 Original message:Hi, ‐‐‐‐‐‐‐ ...
📅 Original date posted:2018-07-06
📝 Original message:Hi,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 5, 2018 12:20 PM, William Casarin <jb55 at 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 <jasonles at 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
📝 Original message:Hi,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 5, 2018 12:20 PM, William Casarin <jb55 at 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 <jasonles at 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