В Wed, 31 Jul 2019 01:13:46 +0000 Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Firstly, I would like to propose that some types be reserved for > proprietary use. These proprietary use types are, in general, for > private use by individuals and organizations who want to use PSBT in > their processes. These are usefule when there are additional data that > they need attached to a PSBT but such data are not useful (or > available) for the general public. I think private formats should have at least a basic format: they should start with a prefix. This way different prviate formats can be distinguished by this prefix, and there will be no risk of unintentional confusion. Private types can start with the size of the prefix, and then organization can choose any prefix they like, or no prefix, if the size is of the prefix is 0 (means they are fine with possible conflicts with other empty-prefix private types) > Lastly, I would like to propose the canonical method for mult-byte > types. We designate a specific type to indicate that the type is > multiple bytes. When such types are observed, parsers should move onto > the next byte and interpret that as the type, keeping in mind the > number of bytes that were read in for the type. > > I propose that we use 0xFF as this designated type. When a parser sees > an 0xFF value as the type, it reads the next byte as being part of the > type. So two byte types will be of the form 0xFFXX. This method allows > us to do a prefix match in order to quickly identify the type being > used. For types with more bytes, simply use another 0xFF byte. So > three byte types would be of the form 0xFFFFXX, four byte, > 0xFFFFFFXX, and so on. When multi-byte types are specified in the > BIP, they should be specified in this full length form, i.e. two byte > types as 0xFFXX. Why not just say that the types should be encoded as 'compact size unsigned integer' ? This format for variable length integer encoding is already used in the BIP for other fields, and thus will not add any additional complexity to the parsing. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
