Published on: 2015-10-23T15:57:14+00:00
In October 2015, there was a discussion on the bitcoin-dev mailing list about Bitcoin Improvement Proposal (BIP) version 1. Luke Dashjr disagreed with adopting the proposal as is because multi-push OP_RETURN outputs were not standard transactions and could not be relied upon for network relay. He suggested waiting for additional capabilities to be deployed in the network before specifying a version 2 payment code. Justus Ranvier argued that version 1 payment codes were designed to be deployable without requiring network-level changes and acknowledged that multi-push OP_RETURN outputs would be standard in v0.12.0 of Bitcoin.Luke Dashjr expressed concerns about the "notification address" requirement in a proposal, as it would lead to address reuse and blockchain spam. He suggested using a single zero-value OP_RETURN output with two pushes instead. Justus Ranvier acknowledged that this portion of the proposal was not ideal but emphasized the goal of making the proposal usable on as many mobile/light wallets as possible. Dashjr argued that BIPs should not be designed around current software and that software upgrades are necessary regardless.There was also an email exchange regarding BIP 63, where Peter Todd expressed his inclination to shelve work on it due to other priorities. Several people offered to send donations to advance the BIP, but no donation address was posted. Todd suggested that someone else could take up the work if interested.Justus Ranvier shared an RFC on April 24, 2015, for a new type of Bitcoin address called a payment code. Payment codes are SPV-friendly alternatives to stealth addresses that positively identify senders to recipients and require less blockchain data storage. They can be publicly advertised without compromising financial privacy. Luke Dashjr expressed concerns about the "notification address" requirement in the proposal, suggesting an alternative approach using a single zero-value OP_RETURN output with two pushes.The concept of identity in relation to payment codes was discussed, with the understanding that it refers to a specific extended public/private key pair rather than conventional personal information. The discussion also touched on privacy concerns in SPV clients and suggested measures such as connecting exclusively through Tor and using varying bloom filters to enhance privacy.Brian Deery expressed worries about payment codes, particularly regarding the explicit tying of identities to them and the potential for identity linkage in bloom filter clients. There were suggestions for improving privacy in SPV clients by using multiple peers, filtering subsets of addresses, and varying the addresses being monitored.One of the main challenges with payment codes is that they rely on making dust payments to a constantly reused address, which undermines the privacy it aims to provide. This method also doubles the data sent for one-time anonymous donations. To address these issues, Brian suggests some ideas such as using even or odd DER encoding to save bytes and deriving the chain value from the x value to save more bytes. Another suggestion is to encode the "x value" into the signature's R value to make the transaction appear like a standard bitcoin transaction and eliminate the need for op_return.In terms of privacy, Brian proposes the concept of a common meeting point where the receiver of the payment code would trial-decode all payment codes sent to a pre-specified dead drop address, such as a charity address. This would require more effort from the receiver but would provide privacy regarding the number of people interacting with them.The proposed payment code scheme establishes a shared chain once and does not require reestablishment, improving upon the stealth address proposal. However, there is no solution presented for scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses.Overall, payment codes offer SPV-friendly alternatives to stealth addresses with features like sender identification and automatic transaction refunds. They require less blockchain data storage compared to stealth addresses but face challenges in terms of privacy and data efficiency. The provided link contains an RFC detailing the payment code proposal.
Updated on: 2023-08-01T12:16:22.615116+00:00