📅 Original date posted:2019-07-31
📝 Original message:В Wed, 31 Jul 2019 01:13:46 +0000
Andrew Chow via bitcoin-dev <bitcoin-dev at 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.
Dmitry Petukhov [ARCHIVE] /
npub10r…9afdw
2023-06-07 18:19:46
in reply to nevent1q…8s83
Author Public Key
npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwPublished at
2023-06-07 18:19:46Event JSON
{
"id": "c87ea83123651aa536d754c448a9f6b38628a08bd7fb9bcdee2a9b6629298444",
"pubkey": "78f5a82a0b64fb3c18bd33a69c53b1af612b3ac8dd81e12f74ba62f3793dac05",
"created_at": 1686161986,
"kind": 1,
"tags": [
[
"e",
"956f6265a8c9ceac600b604046bb23a1593523623adad8fb5fe377e26fe5d166",
"",
"root"
],
[
"e",
"6634ff29c084d44d2329099f96896db85d89f00f98f7cdc00b694ae8fb147099",
"",
"reply"
],
[
"p",
"ca8c3347ed582ff8fb2e2445e0b760ad336b2d74ae0d50208713d2516a316c04"
]
],
"content": "📅 Original date posted:2019-07-31\n📝 Original message:В Wed, 31 Jul 2019 01:13:46 +0000\nAndrew Chow via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nwrote:\n\n\u003e Firstly, I would like to propose that some types be reserved for\n\u003e proprietary use. These proprietary use types are, in general, for\n\u003e private use by individuals and organizations who want to use PSBT in\n\u003e their processes. These are usefule when there are additional data that\n\u003e they need attached to a PSBT but such data are not useful (or\n\u003e available) for the general public.\n\nI think private formats should have at least a basic format: they\nshould start with a prefix. This way different prviate formats can be\ndistinguished by this prefix, and there will be no risk of\nunintentional confusion.\n\nPrivate types can start with the size of the prefix, and then\norganization can choose any prefix they like, or no prefix, if\nthe size is of the prefix is 0 (means they are fine with possible\nconflicts with other empty-prefix private types)\n\n\u003e Lastly, I would like to propose the canonical method for mult-byte\n\u003e types. We designate a specific type to indicate that the type is\n\u003e multiple bytes. When such types are observed, parsers should move onto\n\u003e the next byte and interpret that as the type, keeping in mind the\n\u003e number of bytes that were read in for the type.\n\u003e \n\u003e I propose that we use 0xFF as this designated type. When a parser sees\n\u003e an 0xFF value as the type, it reads the next byte as being part of the\n\u003e type. So two byte types will be of the form 0xFFXX. This method allows\n\u003e us to do a prefix match in order to quickly identify the type being\n\u003e used. For types with more bytes, simply use another 0xFF byte. So\n\u003e three byte types would be of the form 0xFFFFXX, four byte,\n\u003e 0xFFFFFFXX, and so on. When multi-byte types are specified in the\n\u003e BIP, they should be specified in this full length form, i.e. two byte\n\u003e types as 0xFFXX.\n\nWhy not just say that the types should be encoded as 'compact size\nunsigned integer' ? This format for variable length integer encoding is\nalready used in the BIP for other fields, and thus will not add any\nadditional complexity to the parsing.",
"sig": "b3bdc432d430af4daede55274384ccf0e3079838b6d1d492e2d76cb8d4e0d727790cd281e9cfeda226d9c8a30e983a3efbe35d10b4b80f6bb4d4ae3da7b37988"
}