Author: Mike Hearn 2015-07-20 14:40:36
Published on: 2015-07-20T14:40:36+00:00
The email suggests a possible solution to the BIP 70 usability problem without servers by using upgraded QR codes that have more space and optimizing BIP 70. The first topic discussed is the High Capacity Colored Two Dimensional Codes paper, which extends standard QR codes with color for increased capacity while maintaining scanning robustness. Another interesting paper is DualCodes, which overlays one QR code on top of another using shades of gray for an enhanced reader to extract the second code, with digital signatures as a possible use case. The authors could be contacted to see if they would open source their work. If a certificate's format was defined, including its own Certificate Authorities (CAs), a certificate could be as small as 32 bytes for the ECC signature plus the length of the asserted email address. A weaker curve with 64 bits of security could also be used instead of the 128-bit curve for Really Strong Security™, as long as the short CA keys expired frequently, like once a month. Defining our own PKI would allow for these shorter expirations, and certificates that expire monthly is not an issue if the wallet has a way to automatically refresh the certificate by using a longer term stronger credential. A QR code with a single payment address could look like 'bitcoin:1aBcD1234....?x=serialized_payment_request,' but if an embedded reader was required, legacy could be scrapped and a binary BIP70 request could be serialized directly into the QR code. Andreas' wallet can already handle this, but it is unknown what the situation on iOS is like. If the DualCodes system was used, the primary QR code could be an unsigned payment request, and the second layer could be the signature/pki data. Lastly, the email discusses getting response data back to the recipient and the idea of having a store/forward network for private responses or implementing the well-known "Stealth Address" / ECDH in the payment protocol proposals. However, these ideas come at the cost of restoring a wallet from seed words not being possible. The email suggests using servers to store Payment messages for people, and nodes could shard themselves by announcing in their addr messages that they only store Payment metadata for e.g. the half which has a hash starting with a one bit. Regular DoS issues would be present, but any P2P network that stores data on the behalf of others has these.
Updated on: 2023-06-10T02:58:50.729372+00:00