BIP 351: Private Payments

The newest kid on the block is BIP 351, or “Private Payments.” Private Payments strikes a middle ground in trade-offs between BIP 47 and Silent Payments, minimizing the potential impact and issues of a notification transaction (while still requiring one) and reducing the scanning requirements to only scanning OP_RETURNs (while still requiring a full node). Private Payments was proposed in July of 2022 by Alfred Hodler and Clark Moody.

How it works

When Alice goes to send funds to Bob, she takes (1) Bob’s public key encoded in his payment code and combines it with (2) a shared secret she generates to create a unique one-time address to use for a notification transaction. She then generates a unique notification code to include in the OP_RETURN of the notification transaction, creating a transaction that does not re-use a notification address (unlike BIP 47), but does stand out on-chain (unlike Silent Payments). Once she has sent this notification transaction, she can then generate a new, unique address for each subsequent payment to Bob without any links on-chain, and no direct link between any of her UTXOs and Bob’s notification address.

When Bob wants to check for received funds, he checks the OP_RETURN on every transaction since he generated his payment code for those with OP_RETURNs including a notification code that matches his private key. When he finds one that matches, he can then add all derived addresses to a watch list and monitor them for transactions just like a normal Bitcoin wallet. As this only requires checking the OP_RETURN field in each transaction instead of performing validation of every input and output, it’s necessarily much lighter on requirements than that of Silent Payments. While this still precludes the simple usage of light wallets (similar to Silent Payments), it would be easier to off-load the validation of OP_RETURNs to an external (trusted) service.

Advantages and trade-offs

As Private Payments requires both a notification transaction and a full node for proper scanning, it strikes something of a balance between the two other proposals without fully gaining the benefits of BIP 47’s notification transactions and the ability to use low-bandwidth light wallets, or the scaling and privacy improvements from the omission of a notification transaction in Silent Payments. It could still pose an interesting approach for light wallets that are willing to trust an external OP_RETURN validation service, however.

Advantages over Silent Payments

• Easier wallet scanning
  • As a receiver is notified on-chain of what derivation path will be used for payments, he can scan OP_RETURN outputs for notifications sent to him and then pre-generate many possible addresses and check them using a standard Electrum server or BIP 158 filter. This requires less bandwidth and compute compared to Silent Payments scanning, both for the back-end and the user’s wallet itself.

Trade-offs versus Silent Payments

• Worse on-chain efficiency
  • As a notification transaction is required before the first financial transaction, sending a BIP 351 payment ultimately requires a minimum of two on-chain transactions (and thus fees). While subsequent payments to the same payment code do not require new notification transactions, this initial burden makes them inefficient for one-off payments.