Author: Andy Schroder 2014-10-20 15:12:08
Published on: 2014-10-20T15:12:08+00:00
In the email exchange between Mike Hearn and Andy Schroder, the topic of discussion is a Bitcoin payment protocol over Bluetooth. They discuss the issues with the existing protocol, including the use of an unauthenticated Bluetooth connection for Bluetooth 2.1 and the lack of acknowledgement failure message possible in the payment protocol. The conversation also touches on the amount of data stored in QR codes and the limit of offline transactions of a wallet. The two experts talk about the need for a lightweight library that can perform ECDH key agreement using secp256k1 and then do AES+HMAC on framed messages. The discussion revolves around the need for dedicated blockchain access, as not everyone can afford or have access to cellular internet plans. Providing a full-fledged WiFi connection to the customer would require a sophisticated proxy server that allows only access to Bitcoin nodes, which can be difficult since every node does not know all of the nodes in the network.In addition, making the customer's phone automatically connect and disconnect from this service without leaving a saved access point name in their WiFi access point list is cumbersome. Therefore, having dedicated blockchain access is necessary. The PaymentDetails portion of the PaymentRequest has an additional payment_url approach, which is a bit sloppy of a solution since it requires defining some kind of timeout at which point the QR code itself becomes invalid.A much better approach is to have the PaymentRequest formatted and signed on demand when the URI is being resolved. However, this means abandoning the h= mechanism, leading to the question of what to do instead of the h= parameter while still maintaining a trust anchor with the payee. Another option is to do the hashing to the payment request before adding the payment_url to the payment request, but this can allow a hacker to change the payment_url.
Updated on: 2023-06-09T03:11:11.933208+00:00