[BIP proposal] Private Payments [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-07-11T10:28:40+00:00


Summary:

In an update to a previous specification, it has been decided that Bob does not need to watch all address types he's advertising. Instead, when notifying him, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. The new payload has been extended to 73 bytes and defined as `BIPXXXX + notification + N_Alice + address_type`. Previously, the spec had stated that Alice should construct a 72-byte OP_RETURN output whose value would be set to `BIPXXXX + notification + N_Alice`. Damian James Williamson questioned the legibility of the blockchain and the fungibility of UTXOs in a proposal. KING JAMES HRMH replied, stating that the blockchain must be legible for it to be an indelible record, and that Bitcoin is only fungible because it uses the blockchain. The email also included contact information for Damian's company, Willtech, as well as links to their website, duigco.org, and other projects.A proposal to use bech32 instead of base58 for more compact QR codes has been agreed upon. Base64 is a big offender as it not only does not auto-compress, but also triggers binary mode that almost doubles the size of the QR. The Blockchain Commons offers other Airgap QR and TorGap UR efforts, including NFC encrypted Airgap & crypto-request/response flows.The conversation between Clark and Alfred discussed the proposal to use bech32 instead of base58 for more compact QR codes. They both agreed that it is a good proposal. They also discussed the possibility of a third-party service offering to publish OP_RETURN notification payloads in the blockchain for a fee without linking the notifier's identity to their wallet. Another alternative discussed was publishing the block height along with the notification data contained within that block.A new payment code standard proposal is being put forward that builds on the idea of payment codes under a new BIP with some principal differences. The proposed standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist, but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.In a recent bitcoin-dev thread, there was a discussion around the mechanism to demand that a notification transaction meets some minimum miner fee. However, it was pointed out that this mechanism is not safe against miners as they can pay themselves arbitrarily high fees with no downside. One suggestion made was that the spammer has to publish at all. Another suggestion put forward was to do a timelocked sacrifice with OP_CSV.Bryan suggested using Tor hidden service to publish instead of using OP_RETURN while keeping the details of the transaction off-chain. Alfred pointed out that this method is an off-chain solution and it won't work in an offline regime. He also mentioned that Tor keys can be derived from master keys, but this approach isn't much different from Bitmessage notifications in BIP47.The participants discussed the potential issues that may arise if the number of standard scripts increases significantly. One concern is that wallets will have to watch all of them, which could create a performance hit. Additionally, some wallets may not support certain scripts, leading to confusion when sending funds. One proposed solution is to use Taproot-only, but there are concerns about locking down the BIP to a single script type for future proofing. Instead, participants suggest using address type flags to solve these issues at the expense of having a couple of extra bytes.In a discussion on the bitcoin-dev mailing list, Bryan Bishop suggested an alternative to using OP_RETURN in notification transactions for private payments. He proposed publishing the data on a Tor hidden service that other wallets can check. Ruben Santamarta pointed out that the data on-chain is critical to accessing funds and guaranteeing their availability when restoring from backup.Alfred Hodler proposed a way to make notification transactions more private. He suggests that notification transactions will no longer leave a footprint on the blockchain and instead, will just be a single OP_RETURN containing a value that only Alice and Bob can calculate. Bryan suggested an alternative way to maintain privacy while making notification transactions. He suggested that instead of using OP_RETURN, Alice could publish on a Tor hidden service that other wallets check.The BIP47 standard for creating static payment codes suffered from several issues. The new proposed standard that builds on the idea of payment codes under a new BIP has several principal differences. The new standard will allocate a 2-byte bitflag array that will signal address/script types that the receiver is deriving. Notification transactions still exist but no longer leave a privacy footprint on the blockchain. Payment code versioning is no longer done because it creates the potential for fragmentation and disparate standard updates by different parties that don't follow the BIP process.


Updated on: 2023-08-02T06:52:59.917948+00:00