BIP351 Private Payments Support

[privatepayments]

Private Payments (BIP351) is a stealth address system for Bitcoin that allows the user to post a static code and receive payments to a separate address space for each sender.

There are multiple use cases for Private Payments, but the static donation code seems to be the most compelling. A user wishing so solicit donations from the public may safely associate a payment code with her identity and receive funds in a relatively private manner.

The user story is similar to BIP47:

• Receiver posts their payment code
• Sender creates a notification payload and either posts it to the chain as an OP_RETURN or to some other bulletin board system
• Receiver scans the chain for these notification payloads and upon finding one, generates the chain of stealth addresses

Improvements over BIP47:

• Supports multiple address types
• Better notification payload privacy
• Smaller notification payloads

For more context, check out privatepayments.org and the Rust reference implementation.

Related to #549. This improvement is not mutually exclusive to BIP47, and wallets could easily support both payment code schemes.

[LLFourn]

question about the scheme: once you've got your notification why can't you just turn that into a xpub. i.e. why can't:

https://github.com/private-payments/rust-private-payments/blob/16f5547ba1f7e8b41bc03b02e6d26c489ae142b6/src/lib.rs#L287-L303

not take an address index and instead just return a shared secret xpub from which you can derive further addresses using BIP32 unharded children. This would make it much more straightforward to integrate at a software engineering level but maybe I'm missing something at the protocol/security level.

[privatepayments]

why can't you just turn that into a xpub

The issue is privacy. An xpub is a nice portable bit of data that can compute all addresses for the future. That means if it ever leaks (from either party), privacy is lost. It also associates the addresses in a linkable way.

Stealth addresses are always derived from private keys for both sender and receiver, so a more secure path within the wallet is required. Wallets could leak the list of addresses, but it is not possible to derive the next addresses given only previous addresses.

[LLFourn]

why can't you just turn that into a xpub

The issue is privacy. An xpub is a nice portable bit of data that can compute all addresses for the future. That means if it ever leaks (from either party), privacy is lost. It also associates the addresses in a linkable way.'

If the shared ECDH secret leaks isn't it also lost though? After some thought I can't see a straightforward adversarial model where leaking an xpub derived from the shared secret is possible but leaking the shared secret is not.

Stealth addresses are always derived from private keys for both sender and receiver, so a more secure path within the wallet is required. Wallets could leak the list of addresses, but it is not possible to derive the next addresses given only previous addresses.

I understand this but it assumes that the implementation doesn't just save the shared ECDH secret instead of saving the addresses on disk in which case it would be able to derive all the addresses for that code.

I'm interested to know if I'm missing something. Thanks!

[privatepayments]

Implementations might be lazy and send the xpub to an external service, which would compromise privacy going forward.

In any case, I'm not sure this is the venue to debate the merits of the BIP.

[notmandatory]

Closing as inactive and likely superseded by #1114 and #1555.