Author: Andreas Schildbach 2014-03-20 08:08:45
Published on: 2014-03-20T08:08:45+00:00
In March 2014, a discussion was held regarding the use of BIP21 URI via NFC or QR code before the implementation of BIP70. The concern was to ensure backward compatibility while also supporting BIP70 and avoiding external servers. The idea of using Bluetooth in the "r" parameter was suggested as a solution to address different payment requests; something like "bt:-". Another suggestion was to include Base43 encoded PR body within the Bitcoin URI, but this was not compatible with BIP21. The question was raised whether base43 encoding was more efficient than base64 encoded request in a binary QR code format, considering its increased complexity and noncompatibility. Alphanumeric QR codes have an alphabet of 45 characters, of which only 43 are used because space and % are not allowed in URIs. The inventor of Base43 format wanted it to be URI compatible for use in Android intent dispatcher. However, if URI requirement is disregarded, binary QR codes can also be used. This means users will always have to manually start their Bitcoin app first. Additionally, there is an implementation issue with the ZXing scanner that returns Strings instead of a byte array, so it will choke on \0 characters. The option of extending BIP72 to include encoded payment request in the URL directly and in a backwards compatible way was also discussed. However, it was deemed space inefficient. The Base58-encoded address from BIP21 forces the QR code into binary mode. Despite this, payment request extension cannot be encoded as binary because it needs to stay compatible with the URI standard (RFC 3986). One of the Base64 variants could be used for the PR in this case, but it would still be inefficient.
Updated on: 2023-06-08T00:56:51.294139+00:00