Andrea [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-27 📝 Original message:Hi William, Andrew, list, ...
📅 Original date posted:2018-06-27
📝 Original message:Hi William, Andrew, list,
As noted by William there are some types missing in the global-types definition, because the number of each map for I/O must be known to the parser in order to use the correct definitions for the types. At the moment a parser reading a key-value record does not know whether it should read it as per-input type or per-output, a way to address this is to declare in advance the number of maps and ensure they are ordered (inputs first). If you haven't already worked out some types for that i propose using:
Number of inputs
- key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER = 0x01
- value: Varint
Number of outputs
- key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER = 0x02
- value: Varint
On another note I think we can set a hard limit on the size of the PSBT, currently is 'legal' to produce a very large PSBT with an excessive number of Inputs and Outputs. By excessive I mean that even in the best case scenario (using the smallest possible scriptPubKey as in P2WPKH) it is possible to create a PSBT that would certainly create an invalid transaction (because of its size) when finalized. I haven't found anything related to this in the previous discussions, please ignore this if it was already proposed/discussed.
Cheers, Andrea.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On June 27, 2018 8:09 AM, William Casarin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hey Andrew,
>
> If I'm reading the spec right: the way it is designed right now, you
>
> could create hundreds of thousands of zero bytes in the input or output
>
> key-value arrays. As far as I can tell this would be considered valid,
>
> as it is simply a large array of empty dictionaries. Is this right? I'm
>
> worried about buffer overflows in cases where someone sends a large blob
>
> of zeros to an unsuspecting implementation.
>
> Also, the extensibility section reads:
>
> > Additional key-value maps with different types for the key-value pairs
> >
> > can be added on to the end of the format.
>
> "different types for the key-value pairs", is this referring to new
>
> types beyond the current global, input and output types?
>
> > The number of each map that follows must be specified in the globals
> >
> > section
>
> Is this out of date? Since there is only one type in the global section
>
> now (tx).
>
> > so that parsers will know when to use different definitions of the
> >
> > data types
>
> I'm not sure what this means.
>
> Thanks!
>
> Will
>
>
> ------------------------------------------------
>
> https://jb55.com
>
> bitcoin-dev mailing list
>
> bitcoin-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:Hi William, Andrew, list,
As noted by William there are some types missing in the global-types definition, because the number of each map for I/O must be known to the parser in order to use the correct definitions for the types. At the moment a parser reading a key-value record does not know whether it should read it as per-input type or per-output, a way to address this is to declare in advance the number of maps and ensure they are ordered (inputs first). If you haven't already worked out some types for that i propose using:
Number of inputs
- key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER = 0x01
- value: Varint
Number of outputs
- key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER = 0x02
- value: Varint
On another note I think we can set a hard limit on the size of the PSBT, currently is 'legal' to produce a very large PSBT with an excessive number of Inputs and Outputs. By excessive I mean that even in the best case scenario (using the smallest possible scriptPubKey as in P2WPKH) it is possible to create a PSBT that would certainly create an invalid transaction (because of its size) when finalized. I haven't found anything related to this in the previous discussions, please ignore this if it was already proposed/discussed.
Cheers, Andrea.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On June 27, 2018 8:09 AM, William Casarin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Hey Andrew,
>
> If I'm reading the spec right: the way it is designed right now, you
>
> could create hundreds of thousands of zero bytes in the input or output
>
> key-value arrays. As far as I can tell this would be considered valid,
>
> as it is simply a large array of empty dictionaries. Is this right? I'm
>
> worried about buffer overflows in cases where someone sends a large blob
>
> of zeros to an unsuspecting implementation.
>
> Also, the extensibility section reads:
>
> > Additional key-value maps with different types for the key-value pairs
> >
> > can be added on to the end of the format.
>
> "different types for the key-value pairs", is this referring to new
>
> types beyond the current global, input and output types?
>
> > The number of each map that follows must be specified in the globals
> >
> > section
>
> Is this out of date? Since there is only one type in the global section
>
> now (tx).
>
> > so that parsers will know when to use different definitions of the
> >
> > data types
>
> I'm not sure what this means.
>
> Thanks!
>
> Will
>
>
> ------------------------------------------------
>
> https://jb55.com
>
> bitcoin-dev mailing list
>
> bitcoin-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev