Author: Dmitry Petukhov 2019-08-02 09:18:36
Published on: 2019-08-02T09:18:36+00:00
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.
Updated on: 2023-06-13T20:36:00.373636+00:00