Published on: 2022-10-18T22:46:13+00:00
In a discussion on the bitcoin-dev mailing list, concerns were raised about the security of copy-pasting public keys. Andrew Poelstra clarified that the public key held by the wallet is only used for authentication and never leaves the wallet. He suggested that compromising the wallet's memory is much harder than compromising data on the clipboard. The proposal could even be implemented on a hardware wallet with an out-of-band way to obtain and authenticate public keys.Ruben Somsen proposed a method for recipients to sign their public keys for authentication purposes. However, Bryan Bishop pointed out the need for secure communication of the public key itself. Ruben suggested that whether or not Bob runs the Trustless Address Server himself is the meaningful distinction and proposed depositing signed keys to prevent malicious addresses from being distributed.A member named rot13maxi expressed concerns about clipboard hijacking, where the contents of the clipboard can be replaced with a malicious address without the user realizing it. Bryan Bishop highlighted that this problem also applies to copy-pasting public keys. The discussion emphasized the importance of verifying the accuracy of addresses and public keys before sending any funds.A developer proposed a setup where an address server provides fresh receive addresses to senders, improving privacy and address authentication. When a user wants to pay someone, their wallet asks the address server for an address, which is then signed and returned to ensure its authenticity. This allows the wallet to verify the intended recipient even if the data is intercepted. The developer suggested a protocol for interoperability between wallets and address servers.Another developer suggested an alternative solution involving submitting a transaction paying a placeholder address to the server and receiving a guaranteed unique address in return. If the transaction is not seen within a reasonable time, the server broadcasts the transaction paying the placeholder address. This approach is similar to the BIP78 payjoin protocol.Ruben thanked David for his suggestion and agreed on potential privacy reduction with placeholder transactions. David proposed an alternative method where the sender reveals their intended transaction to the server before receiving the address. This would prevent transaction replay attacks. Dave believes this approach satisfies all design constraints and is essentially the BIP78 payjoin protocol without payjoining.The post discusses a protocol for non-interactive distribution of bitcoin addresses, outsourcing interaction to third-party servers. The sender interacts with the server, which represents the recipient and provides an address from an xpub. One remaining challenge is the gap limit. An alternative mitigation involves revealing the intended transaction to the server before receiving the address. This protocol is useful for users wanting to use light clients, accept privacy degradation, and receive payments non-interactively.
Updated on: 2023-08-02T07:42:25.308687+00:00