rich1.0Andrea [ARCHIVE] (npub18r…8qr6z)https://yabu.me/npub18rpmnsgdeefa9vxvg4sewhx70wjmnhtkcpdxuecyrlyg7ref4eyqd8qr6znjumphttps://yabu.me📅 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