Author: Alex Kotenko 2014-03-20 02:22:19
Published on: 2014-03-20T02:22:19+00:00
The email is from Alex Kotenko who wants to implement support for BIP70 in his point of sale (POS) system. However, he realizes that the use case he needs is not covered by the options proposed by Andreas. Before BIP70, Alex was sending BIP21 URI via NFC or QR code and still needs to use it for backward compatibility. He also wants to support BIP70 but avoid using external servers as his POS concept is that everything happens between payer's phone and payee's POS device. Therefore, the BIP72 HTTP(S) link inside Bitcoin URI is not suitable for him. Andreas offered an option to include Base43 encoded PR body inside the Bitcoin URI, but it is not backward compatible with BIP21. This means there is no way for Alex to keep backward compatibility with all wallets not supporting NFC and BIP70 while keeping things inside the POS without the need for external servers. Alex understands the intention behind base43 encoding and non-compatible URI, but he wonders whether base43 encoding is compared to base64 encoded request in a binary QR code format. He questions how much is actually won in total bytes capacity at the price of non-compatibility and increased complexity. He suggests extending BIP72 to include encoded payment request in the URL directly in a backward-compatible way. The email thread includes a response from Mike Hearn regarding BIP standardization, where he thinks the VIEW intent seems like an obvious one. Bluetooth support should come later if/when encryption/auth on the RFCOMM link is put in place (probably SSL).
Updated on: 2023-06-08T00:56:24.816161+00:00