[Feature Request]: 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.

[acrespo]

Hello there,

We are long-time fans of paynyms here! Bitcoin needs an interoperable identity system to make p2p payments easier.
However, the original (BIP47) paynym protocol has fallen a bit behind the times since it doesn't support taproot, but more importantly, it doesn't support lightning.

It's nice to see a proposal trying to tackle those issues. But unfortunately there some other, more nuanced, UX issues which BIP47 presented and this proposal (AFAIU) does not completely solve. For example, handling well what happens if the owner of a paynym/payment code loses their keys. In particular, everyone that has them as a "contact" will keep sending money to an irredeemable address, effectively burning money.

We are still on the look for other proposals that can solve these issues. Let me know if you have some feedback or ideas on this topic!

[privatepayments]

A human-readable identifier layer could be added on top, similar to Lightning Address or nostr's NIP-05, but that is out of scope for the BIP itself. These payment codes are not meant to be identities.

In broader terms, main chain bitcoin always suffers from the case of lost keys. For a payment code system, this does present a challenge as you point out, since anywhere along the line, the receiver could lose their keys. A Lightning Address style alias could help mitigate the issue, but that introduces more complexity and the requirement to keep the hosting server secure or outsource to a centralized identity directory like PayNym. Such a central server is now a honeypot on top of an otherwise decentralized privacy protocol.