Sender Initiated Payjoin Via BIP352 (SilentPayjoins)

[0xBEEFCAF3]

Sender-Initiated Payjoin via BIP352 (SP)

The following is a brain dump of my notes and thoughts on how sender initiated payjoins could work via BIP-352 style silent payments. I don't propose a solution or a new protocol but I do list many problems we need to think about while designing the ideal solution

Overview

In a typical BIP-77/78 payjoin flow, the recipient is responsible for providing the sender with a fresh payment address through BIP-21. That URI also includes BIP-77–specific parameters to enable HPEK communication via the BIP-77 directory. With silent payments, however, the sender can already know the BIP-77 subdirectory that the recipient is using, thereby eliminating the need for an additional out-of-band communication round.

How It Works

Recall that BIP-77 subdirectory IDs are simply the shortened hash of a compressed ephemeral public key, often referred to as ShortIds.

Naïve Strawman Flow

1. Parsing the SP Address: The sender parses the SP address, extracts the scan public key, and derives the ShortId for the recipient's subdirectory.
2. Publishing the Original PSBT: The sender publishes the original PSBT—this step follows the standard BIP-77 payjoin process.
3. Recipient Response: The recipient long-polls the subdirectory and publishes the payjoin.
4. Finalizing the Transaction: The sender completes the payjoin and broadcasts the transaction.

This flow presents an obvious denial-of-service vector, as an attacker could overwrite the payjoin with arbitrary data. Additionally, using one-time subdirectories for SP undermines the intended purpose.

Linked Subdirectory ID

One mitigation strategy is to calculate the next subdirectory ID based on the contents of the previous one. For example, the next ShortId could be derived as the hash of the current subdirectory's contents. In this approach, the recipient must track the last used subdirectory for sender-initiated payjoins, while the sender must identify the most recent unused subdirectory. This method, however, places a significant burden on both parties and may not be worth pursuing.

Write-Once Strategy

A variation of this approach is to enforce a write-once rule, which could make the system more robust. More details on this strategy can be found here.

Append Semantics for Subdirectories

The basic concept is described in Change the Directory Semantics to Support Multiparty Payjoin:

Instead of rejecting POSTs to the same directory, values could be concatenated. With proper padding, each subdirectory would function as an append-only array of fixed-size messages, unlike previous approaches where the shared buffer spans multiple subdirectories.

Similar to an append-only log, earlier messages would expire after some time. Before expiration, writes could be temporarily rejected if a size limit is exceeded.

These append-only semantics also serve as a signaling mechanism for the recipient. For instance, the recipient can perform a GET request to /{subdir}/size and, if the size has increased since the last check, use a ranged GET to fetch new messages. Subdirectories would have a configurable expiration period, and old messages would be discarded. Note that this approach could inadvertently leak information about the number of payments received.

RBF and Mempool Usage

Alternatively, the sender could initially submit a low-fee silent payment to the recipient. After performing ECDH, the recipient could bump the fee and complete the payjoin, submitting the proposal to their subdirectory ID. This approach has two main drawbacks:

• Confirmation Risk: There is a risk that the transaction might get confirmed before the payjoin process can complete.
• Privacy Concerns: If chain analysis tools monitor unconfirmed transactions, the payjoin transaction could be easily fingerprinted. Moreover, unconfirmed transactions can leak additional privacy heuristics, as discussed in this paper.

[nothingmuch]

A high effort approach, and somewhat inefficient but not impractical approach would be a broadcast channel based introduction service in conjunction to the directory.

Imagine a broadcast channel bulletin board, where all parties can read all messages. HPKE protects the payloads so that clients can decrypt messages to them. This can be done with the silent payments key material.

In order to prevent flooding, senders could request a rate limiting anonymous credential from such a service, by proving ownership of a UTXO. The rate limiting can be adjusted dynamically based on load, guaranteeing a maximum ingress rate for all listeners. We've previously discussed potentially using such a mechanism for the directory and/or relays in case of abuse, but here this would be more prudent to ensure receivers don't get flooded.

These introduction messages would be very short, just a directory URI + short id, where the receiver can obtain the sender's proposal. The ECDH half would be indistinguishable from randomness due to the sender's entropy contribution, so the only difference is that the short id would not be hash of the receiver's key, but a random identifier.

I can provide details for the cryptography needed to realize this if anyone is interested in pursuing this.

[0xBEEFCAF3]

long term yes, this is something that I plan on working on -- especially in the context of multiparty pj -- for the silentpayjoins POC hackathon project this might be overkill

[nothingmuch]

Perhaps a more lightweight approach than my previous suggestion, is for the sender to allocate a static subdirectory with append semantics, and for receivers to arrange for cover traffic (read and write) to be generated by one or more 3rd parties in order to hide the receiver's temporal habits.

Alternatively, there are metadata resistant store & forward messaging protocols, https://cwtch.im is the main one that comes to mind but I have no experience with it, using an off the shelf protocol is probably more advisable from both a privacy engineering and efficiency/scalability point of view but discounts the fact that bitcoin inherently has an access control / rate limiting mechanism (UTXO ownership) so may be significantly more complex than is required, so perhaps the best approach is to adapt an off the shelf approach.