Author: Wladimir 2012-01-31 10:22:11
Published on: 2012-01-31T10:22:11+00:00
The discussion centers around BIP 21 and BIP 20, with the former being preferred. The need for forward compatibility with optional fields is highlighted, and there is a need to define how clients handle fields they don't know about. It is suggested that "expires" and "message" could go into BIP 21 as they are easy to implement and do not require much discussion. The "send to private address" field may require more effort to implement than the simpler "expires" and "message" fields and should be deferred to a later BIP. The inclusion of a dual representation (block or timestamp) is also discussed. Simple is deemed best, and while a block number represents Bitcoin's pulse, there is no guarantee that a block will be discovered at any particular moment. It is suggested that people have been coordinating events based on a UTC timestamp for decades and it would be advisable to stick with it. Regarding the "version" field, it adds unnecessary complexity. Pretty much everything needed within the Bitcoin URI scheme can be encoded with suitable optional fields, making the whole structure forward compatible. A version field seems redundant. Finally, the URI signing mechanism needs more work and should be deferred into a dedicated BIP. In terms of client handling, it is suggested that older clients detect schemes they don't understand and give the user an appropriate error message. There is uncertainty around the 'send' parameter and the 'version' parameter in BIP 21, with questions raised about what they mean, whether they are necessary and how clients should handle them.
Updated on: 2023-06-05T02:06:45.828788+00:00