Published on: 2019-08-04T00:15:17+00:00
The email thread discusses the idea of having a prefix string in BIP174 and how it adds complexity to parser code. Some people are against the idea, while others argue that the benefit for the whole industry is greater if there is a conflict-avoidance prefix. The author suggests using a specific type for all (global, input, and output) in BIP174, which means "see the BIP numbered in the next byte." This would allow for a BIP43-ish system for BIP174. The author also mentions that POR COMMITMENT and their current signature protocol proposal should go in there. They will keep an eye on the bips repo and implement it if someone pings them once things settle down.In a discussion about implementing a prefix string for private types, Andrew Chow spoke to some individuals who didn't like the idea because they had already created proprietary types without a prefix. This would add additional complexity to the parser code. However, others suggested that those who didn't want the added complexity could simply ignore it altogether. Since this is a private construction, and their private format specifies 'no prefix,' they can just disregard everything that doesn't start with "{0xFC}|{0x00}". The only added complexity would be one condition check. Others argued that having a conflict-avoidance prefix as the first thing after 0xFC would benefit more people in the industry than those who have already implemented proprietary types. Those who don't want to use the prefix can set it to 0x00, and the set of possible conflicting types are limited only to those entities that made this explicit decision. As for those who have already created squatted types, it only matters if they squatted on the 0xFC type in particular. In other cases, they will need to implement changes anyway to be compatible with the BIP. It was suggested that they consider the small burden of one additional condition check for the benefit of reducing interoperability problems between future PSBT/private types implementers.After speaking to some individuals, Andrew Chow has decided to simplify the implementation of proprietary types in Bitcoin by not using a prefix string. Instead, he suggests using {0xFC}|{private_type} with an optional prefix string that is strongly recommended. The concern was that people would use unused type values instead of following the specification for proprietary types, which would add complexity to the parser code. Since public parsers will not be enforcing the rules for proprietary types, it does not make sense to specify and enforce how they should be. The key is just an opaque data blob. Andrew also confirms that Compact Size Unsigned Integers will be used for the field types and will be minimally encoded CSUints. For proprietary types, there will only be one proprietary type, 0xFC, followed by a variable length string that serves as a unique identifier to prevent usage of proprietary types outside of private contexts. The actual type for data will then follow, 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, a single 0x00 byte can be used. It's important to note that for public software, these proprietary types don't need to be handled at all. Therefore, they do not need to check the string or the data type. Although it is not necessary to enforce the above rules about proprietary types, it is necessary to use the proprietary type value.It has been decided that Compact Size Unsigned Integers will be used for field types in an upcoming project. For proprietary types, one suggestion is to use a unique identifier, in the form of a variable length string prefixed with a compact size unsigned integer, followed by the actual type for the data as defined by the user. This will help prevent usage of proprietary types outside of private contexts. A single 0x00 byte can be used if no prefix is wanted. Public software does not need to handle these proprietary types and does not need to enforce the above rules except for the use of the proprietary type value.The suggestion has been made to use Bitcoin compact uint, which is already implemented in all bitcoin applications, wallets and libraries. This would be a logical choice for PSBT consumers. For certain proprietary applications, multi-byte keys could also be used where the first byte defines the application type and the next bytes define application-specific fields. It is recommended to set proprietary bytes to 0xF0-0xFC or 0xE0-0xEF, possibly using E for Enterprise.In a Bitcoin Development email thread, Dmitry Petukhov suggested that private formats should have at least a basic format with a prefix to distinguish different private formats and avoid unintentional confusion. He proposed that private types can start with the size of the prefix, allowing organizations to choose any prefix they like or no prefix if they are fine with possible conflicts with other empty-prefix private types.
Updated on: 2023-08-02T01:13:15.378026+00:00