BIP-47: Reusable payment codes

[justusranvier]

https://github.com/bitcoin/bips/pull/159

Payment codes are a technique for creating permanent Bitcoin addresses that can be reused and publicly associated with a real-life identity without creating a loss of financial privacy.

They are similar to stealth addresses, but involve a different set of trade-offs and features that may make them more practical.

You can publicize your payment code in the same way that you can publicize your email address. Even if everyone knows your payment code, nobody can monitor the blockchain to see how many payments you have received or which transactions are yours.

If you receive an incoming transaction to your payment code, the act of learning that you received funds tells you the payment code of the person who sent the transaction. This means transactions sent to payment codes do have the "from address" that's missing from Bitcoin wallets and that many users would like to have.

Since transactions involving payment codes have a from address, the recipient of a payment can send a refund to the sender without requiring additional information.

Unlike stealth addresses, detecting incoming payments does not require scanning the entire blockchain and all transactions. Any method used by light clients to obtain their balance normally also works with payment codes. This means a light client can use payment codes without outsourcing their privacy to a trusted full node.

Payment codes have different privacy features than stealth addresses:

• Payments sent to a stealth address are obviously identifiable to network and blockchain observers as sends to a stealth address and could conceivably be censored. Payments sent to a payment code are not distinguishable from traditional Bitcoin transactions
• Payment codes leak an upper bound on the number of incoming notification transactions a known payment code has received. The senders of those payment codes, whether not a particular notification transaction is a valid payment code or not is not leaked. Notification transactions are identifiable by a network or blockchain observer and could conceivably be censored.
• Stealth address transactions put the information that's contained inside a payment code notification in every transaction. Payment code notification transactions include an extended public key that only needs to be sent once to each recipient and is which is valid for 2³² subsequent payments.

The payment code standard does not currently support multisig payment codes, and there's no obvious way to add support for them without either losing desirable features or failing to provide the additional security that multisig addresses are supposed to provide. It might be possible to use threshold signature techniques to accomplish the goal of allowing multiple parties to share control over a payment code without requiring OP_CHECKMULTISIG scripts. This will be a subject for future investigation.

The full description of the protocol with illustrations is available here:

https://github.com/OpenBitcoinPrivacyProject/bips/blob/master/bip-0047.mediawiki

[unamis76]

This looks really interesting, and I think it could be used, for example, as a donation address (or donation payment code, in this case). But there's something I'm not sure I understand (and forgive me if this is simple, but I'm not a very technical person Bitcoin-wise): if a payment code was given for donation, would each transaction to this code "redirect" the funds to different addresses? Will these codes make a lot of addresses via the same seed and use each address for each transaction?

[justusranvier]

This looks really interesting, and I think it could be used, for example, as a donation address (or donation payment code, in this case). But there's something I'm not sure I understand (and forgive me if this is simple, but I'm not a very technical person Bitcoin-wise): if a payment code was given for donation, would each transaction to this code "redirect" the funds to different addresses? Will these codes make a lot of addresses via the same seed and use each address for each transaction?

A payment code is an address that each sender can use to derive up to 4 billion deposit addresses unique to them.

If a charity advertises a payment code for donations, each individual donation transaction would send funds to a unique address.

[unamis76]

This looks really interesting, and I think it could be used, for example, as a donation address (or donation payment code, in this case). But there's something I'm not sure I understand (and forgive me if this is simple, but I'm not a very technical person Bitcoin-wise): if a payment code was given for donation, would each transaction to this code "redirect" the funds to different addresses? Will these codes make a lot of addresses via the same seed and use each address for each transaction?

A payment code is an address that each sender can use to derive up to 4 billion deposit addresses unique to them.

If a charity advertises a payment code for donations, each individual donation transaction would send funds to a unique address.

So I guess I understood correctly the usage of payment codes This is great system, clearly needed on the Bitcoin network, as it will avoid address reusage greatly. I really hope this gets some traction.

[tacotime]

I would rather we stick to the stealth address format that exists and finalize it instead of switching to another construction stealth addressing, when it's being used in essentially the same way.

Stealth addressing works OK as is, however we can transmit the extra data from that would normally be disclosed in an OP_RETURN out-of-band via an intermediary like Bitmessage. Essentially this appears to be your described protocol, and I think it'd be preferred if we worked within the established protocol as an extension of the proposed BIP0063, and backwards compatible with the described address format.

Additionally, solicitation (Notification Transaction) should be done out-of-band, rather that by the use of the blockchain and OP_RETURN tagging. I think it's potentially wasteful, aside from being permanently embedded in the blockchain and by which causing a loss of privacy. A proper out-of-band solution for stealth transacting should never need to resort to blockchain access, as far as I am concerned.