{"type":"rich","version":"1.0","title":"Andrea [ARCHIVE] wrote","author_name":"Andrea [ARCHIVE] (npub18r…8qr6z)","author_url":"https://yabu.me/npub18rpmnsgdeefa9vxvg4sewhx70wjmnhtkcpdxuecyrlyg7ref4eyqd8qr6z","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-27\n📝 Original message:Hi William, Andrew, list,\n\nAs 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:\n\nNumber of inputs\n- key (None, only the type): PSBT_GLOBAL_INPUT_NUMBER = 0x01  \n- value: Varint \n\nNumber of outputs\n- key (none, only the type): PSBT_GLOBAL_OUTPUT_NUMBER = 0x02\n- value: Varint\n\nOn 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.\n\n\nCheers, Andrea.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\nOn June 27, 2018 8:09 AM, William Casarin via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e ​​\n\u003e \n\u003e Hey Andrew,\n\u003e \n\u003e If I'm reading the spec right: the way it is designed right now, you\n\u003e \n\u003e could create hundreds of thousands of zero bytes in the input or output\n\u003e \n\u003e key-value arrays. As far as I can tell this would be considered valid,\n\u003e \n\u003e as it is simply a large array of empty dictionaries. Is this right? I'm\n\u003e \n\u003e worried about buffer overflows in cases where someone sends a large blob\n\u003e \n\u003e of zeros to an unsuspecting implementation.\n\u003e \n\u003e Also, the extensibility section reads:\n\u003e \n\u003e \u003e Additional key-value maps with different types for the key-value pairs\n\u003e \u003e \n\u003e \u003e can be added on to the end of the format.\n\u003e \n\u003e \"different types for the key-value pairs\", is this referring to new\n\u003e \n\u003e types beyond the current global, input and output types?\n\u003e \n\u003e \u003e The number of each map that follows must be specified in the globals\n\u003e \u003e \n\u003e \u003e section\n\u003e \n\u003e Is this out of date? Since there is only one type in the global section\n\u003e \n\u003e now (tx).\n\u003e \n\u003e \u003e so that parsers will know when to use different definitions of the\n\u003e \u003e \n\u003e \u003e data types\n\u003e \n\u003e I'm not sure what this means.\n\u003e \n\u003e Thanks!\n\u003e \n\u003e Will\n\u003e \n\u003e \n\u003e ------------------------------------------------\n\u003e \n\u003e https://jb55.com\n\u003e \n\u003e bitcoin-dev mailing list\n\u003e \n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}