2 Sender 1 Reciever Payjoin (2S1R)

[arminsabouri]

Rough outline of how we can implement a 2S1R payjoin

General Flow

1. The receiver generates their HPKE key pair and creates two separate BIP21 URIs, each with a different Bitcoin address.

   • All parties share the same subdirectory and encrypt messages using the receiver's public key.

2. The senders create a sweep PSBT and post it to the shared subdirectory.

3. For this process to work, the PJ directory must append PSBT bodies rather than overriding them, which is its current behavior.

   • At this stage, the directory should contain two encrypted payloads.

4. The receiver needs a method to identify where an encrypted payload begins and ends.

   • Ideally, no metadata or magic bytes should be stored, as they could reveal information about the number of participants in the PJ.
   • The solution for this issue is still to be determined.

5. The receiver validates the proposal, merges the two PSBTs, signs the combined transaction, and posts the PJ back to the same subdirectory ID.

   • The reciver will need to post two seperate PSBTs as the senders do not share the HPKE sk.

6. The senders use long polling on the subdirectory ID to detect updates.

   • Each sender reads the updated PSBT, signs their respective inputs, and validates the PSBT during the process.
   • Each sender will POST the signed partially signed PSBT back to the subdir. Encrypting the payload with the recievers pk.

7. Finally, the reciever will broadcast the fully signed PSBT

[nothingmuch]

2S1R wouldn't even need the subdirectory ID to be shared between the senders, the receiver can do all of the PSBT combining out of band. All that's needed is for the senders to opt in to the additional round of communication required, and consent to receiving proposal PSBTs that they cannot fully complete.

I suppose that's a simpler starting point?

The receiver would need to have state & concurrency to detect when this is possible, and to multiplex senders accordingly, as well as merge the data from the two sessions. It seems like other than the additional round of signature aggregation, the senders' and the receiver's state machines would be largely unchanged.

[arminsabouri]

I agree this is simpler. Lets go with this for the first iteration. Do senders need an additional round?
The rounds of comms with this simplified flow should be

1. Senders publish orginal PSBT's to different subdirs
2. Reciever recognizes oppurtunity to merge, and posts proposed PJ psbt to the subdir ids
3. Senders finalize add their signatures
4. Reciever will need to do another merge of the two psbts and then broadcast

[nothingmuch]

4. The receiver needs a method to identify where an encrypted payload begins and ends.

The existing 7168 byte limit seems sufficient

• Ideally, no metadata or magic bytes should be stored, as they could reveal information about the number of participants in the PJ.

Without adding redundant GET requests this leak will be inherent, so I wouldn't worry about that too much. Appended messages will just appear uniform size, by unknown writer.

I don't see a way to mitigate leaking the # of readers without significant complexity increases, e.g. a PIR based directory, p2p transport, or clients generating significant (unreasonable) amounts of cover traffic (both read and write, including in the 2 party case which kind of sucks if that's all you're doing).

Therefore, for this PoC i would just ignore this consideration and as a working assumption just let the directory know the number of parties to a session and not treat that as a problem, if it becomes a censorship risk then alternative transports to a centralized directory are probably the way to go.

That said, in the fan-in setting the receiver has more leeway to add cover traffic, similarly to Loopix.

5. The receiver validates the proposal, merges the two PSBTs, signs the combined transaction, and posts the PJ back to the same subdirectory ID.

   • The reciver will need to post two seperate PSBTs as the senders do not share the HPKE sk.

For multiparty sessions I think it's simpler to use the receiver's key not for DHKEM, but as entropy for a symmetric KDF. The authentication properties of a DHKEM offer little assurances in the multiparty setting anyway, and the short ID no longer leaks this to the directory so it's a private communication channel. All parties to the subdirectory can both read and write. Since AEAD is used in DHKEM and should be used in this symmetric variant, domain separation is ensured, and DHKEM failing early can signal multiparty data.

Senders who are given the same short ID can opt out of multiparty by using DHKEM. Receivers who opt into that can avoid senders from spying on other non-multiparty sends by just posting noise to themselves, which also partly addresses the previously mentioned # of participants leak.

[arminsabouri]

Progress Update

Current Status

In a WIP branch, I have a working example of 2s1R. The flow here is straightforward and adds only one extra round of communication for the senders. This protocol is implemented as an integration test:

1. Senders initiate a normal PayJoin v2 request: It is assumed they received a BIP21 request out-of-band.
2. Receiver identifies the opportunity for a multiparty PayJoin: Optimistically, the receiver merges the two unsigned PSBTs from both senders and signs for their contributed inputs.
3. Senders recognize this as a multiparty PayJoin: They observe unsigned inputs that they did not contribute.
4. Senders sign their inputs: They post back to the original subdirectory.
5. Receiver combines the signed PSBTs: At this stage, all inputs should be fully signed and ready for broadcast. The receiver then broadcasts the transaction.

Missing Components for a Complete POC

To achieve the above, I had to abuse the v2 data structures/typestate. For instance, since we are dealing with multiple parties and different session contexts, I had to make the session contexts public. It makes sense to recreate similar typestate data structures for the v3 multiparty protocol.

I advocate for v3 typestates rather than modifying v2 because v3 may require validation for different criteria and entirely new states.

Sender and reciever validation is also missing:

• Ensuring two PSBTs are mergeable (Step 2 above).
• Updating sender and receiver validations to support unknown inputs/outputs.

Backwards Compatibility and Improvements

At every round of communication, the protocol can downgrade to a previous version of PayJoin:

1. First round: The PayJoin v3 request is still technically a v2 request since the receiver hasn’t initiated an optimistic merge. The receiver retains a signed fallback transaction.

2. Second round: The receiver could send two concatenated payloads (v2 | optimistic v3). Non-v3 clients read up to the v2 max payload size, sign their inputs, and broadcast. V3-aware clients process the full payload and participate in the extra communication round. However, they also retain a fallback v2 transaction they can sign and broadcast at any point.

Roadmap

Phase 0: Experiment (Current Phase)

• Enable a 3-party PayJoin.
• Implement any necessary steps to achieve this.
• Output: A document outlining trade-offs and next steps (this document).

Phase 1: Proof of Concept

• Refactor sender/receiver to validate v3 input/output additions.
• Feature-gate v3-related functions and data structures.
• Ensure backwards compatibility with v2.
• Create an API interface and document trade-offs (e.g., maintainer downsides, simplicity, readability, and breaking changes to the v2 interface).
• Output: Draft PR with mergeable code.

Phase 2: Sub-Transaction Model Privacy Metrics

• Update privacy metric model to use sub-partitions/sub-transactions. Start with the 2-party v2 PayJoin case, then expand to multiparty cases.
• Output: TBD.

Phase 3: Coalition Formation

• Develop a market mechanism enabling multiple non-connected parties to interface for larger batching.
• Output: TBD

Miscellaneous Tasks

• DoS Protection: Use anonymous credentials.
• Proposal Negotiation: Improve proposal handling mechanisms.
• Sybil Protection: Add randomization to mitigate Sybil attacks.
• Output Splitting: Clients should be able to opt in to splitting outputs to create even more subtxs