Published on: 2014-09-15T07:43:32+00:00
In an email exchange, Aaron Voisine proposed that BIP72 should require signed payment requests from the same domain as the merchant. He suggested that merchants could store their signed payment requests on their payment processors' servers, providing a better user experience by showing the actual merchant instead of just the payment processor. However, he did not think it was necessary for BIP72 to require HTTPS, as HTTP is commonly used and the proposed spec allows for other transports like Bluetooth.The conversation also discussed a more efficient approach to adding another field to PaymentRequest that contains an ECC signature calculated using the public key that hashes to the address in the URI. This would involve adding another marker param like &s to the end of the URL. However, there are several downsides to this approach including complexity and concerns about re-purposing the BIP21 address. The discussion also touched on the length of the URL and the possibility of truncating the SHA256 hashes to save characters.Another topic of discussion was the importance of the length of a hash in PaymentDetails/PaymentRequest. It was suggested that including the hash length in the PaymentDetails/PaymentRequest is necessary to prevent a MITM attacker from truncating the hash to lower security.The conversation then moved on to discussing the use of hash functions in generating QR codes for payment requests. There were debates about the optimum length of the hash, with suggestions to leave it open for experimentation. Different hash functions were evaluated, including SHA1, Murmur, and MD5. The discussion also touched on the use of certificates in verifying website authenticity and the potential issues with X.509.A separate discussion focused on whether signed payment requests should be from the same domain and require HTTPS as per BIP72. The proposal suggested adding another marker parameter to the URL and another field to PaymentRequest containing an ECC signature calculated using the public key that hashes to the address in the URI. Upgraded wallets would then expect to find the PaymentDetails signed with the address key. However, there were concerns raised about the complexity of signing and the potential issues with re-purposing the BIP21 address.BitPay tested the impact of adding more bytes to QR codes and found that it made them harder to scan in low-light environments. This was in response to a suggestion that Base64 encoding of SHA256 was overkill and that HTTPS should provide enough security. Adding a hash to QR codes was deemed to make them bloated and harder to scan.Overall, the discussions centered on improving the PaymentRequest system by adding an ECC signature to the URL and PaymentRequest, determining the optimum length of the hash, and considering the scannability of QR codes. There were also debates about the use of certificates, the need for HTTPS, and the limitations of existing hash functions.
Updated on: 2023-08-01T10:18:40.714137+00:00