📅 Original date posted:2019-08-01 📝 Original message:I spoke to some people OOB and they said that they didn't really like the idea of having a prefix string (partially because they've already implemented some proprietary types by simply squatting on unused types). Matching the prefix string adds additional complexity to the parser code. The main concern is that people won't want to actually follow the spec for proprietary types and instead just use some unused type value. So I think instead we should do: {0xFC}|{private_type} and the prefix string can be optional (and strongly recommended) after that. Since public parsers won't really be enforcing the rules for proprietary types, I don't think it really makes sense to specify and enforce how they should be. After all, the key is really just an opaque data blob. In the same vein, it would probably be useful to allow multiple types for proprietary use as originally proposed to make implementation of these easier. If more type are needed, then the private type construction can be used. Andrew On 8/1/19 1:57 PM, Andrew Chow wrote: > > It seems like the consensus is that we should use Compact Size Unsigned > Integers for the field types, so we will do that. The types will be > minimally encoded CSUints. > > For the proprietary types, I will use Dimitry's and Andrew Poelstra's > (lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016713.html) > suggestion. There will be one proprietary type, 0xFC. This will be > followed by a variable length string that is a vendor specific prefix > that serves as a unique identifier to help with preventing usage of > proprietary types outside of private contexts. This will then be > followed by the actual type for the data, as defined by the user of the > proprietary type. > > The prefix will just be a string, prefixed with a compact size unsigned > integer. If no prefix is wanted, then a single 0x00 byte can be used. > > For public software, there is no need to handle these proprietary types > at all so they do not need to check the string or the data type. It is > not necessary to enforce the above rules about proprietary types except > that they use the proprietary type value. > > > Andrew Chow >