Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback



Summary:

In 2015, Andy Schroder and Eric Voskuil exchanged emails discussing the use of a public key via NFC to identify payees without the need for users to log in. However, Voskuil pointed out the security issues that could arise if a public key is reused because anyone could spoof a payer and obtain payment requests. They discussed potential solutions to this problem, including encrypting a secret with the public key before transmission or using an ephemeral key.During their exchange, they also discussed the benefits of using a micro-payment channel for everyday purchases to improve network propagation. They debated the use of a self-signed certificate versus one signed by a Certificate Authority (CA) and how customers are identified on websites versus in-person shopping scenarios.Ultimately, they agreed to get rid of the "h=" parameter and add a "s=" parameter to the bitcoin URL with a unique public key for each session. The discussion revolved around the use of existing parts of the bitcoin URI to establish trust in a public key that the payee sends via bluetooth after the NFC connection.There was debate about using QR+BT vs NFC+BT, and whether to send a unique public key or a session key on each NFC tap. The consensus seemed to be that sending a unique public key over NFC is better than a unique session key, although it will add about 23 characters to the NFC URL.The discussion also covered the encoding squabble between Base58 and Base64url, with Base58 being preferred for its compactness and standardization. Finally, there was concern about abuse scenarios, which could cause denial of service attacks or taint transactions, and suggestions were made for ways to prevent these issues.


Updated on: 2023-06-09T17:55:57.967909+00:00