Payjoin

Also called: PayJoin, P2EP, pay-to-endpoint, BIP78, BIP 78, async payjoin, Payjoin v2.

Payjoin is a payment where the receiver adds their own input to the sender's transaction, breaking the assumption that all inputs belong to the payer.

Payjoin is a way of paying someone in which the receiver also contributes an input to the transaction. The result looks like an ordinary payment, but it breaks a key assumption of chain analysis: that all inputs of a transaction belong to the same person.

How it works (BIP 78)

BIP 78, by Nicolas Dorier, describes the original protocol:

1. The receiver shares a Bitcoin URI (BIP 21) with a pj= parameter pointing to their payjoin endpoint.
2. The sender builds and signs a normal transaction as a PSBT, called the original, and posts it to the endpoint.
3. The receiver adds one or more of their own inputs, adjusts their output, signs and returns a payjoin proposal.
4. The sender checks the proposal, signs their inputs again and broadcasts it.

The original transaction is valid on its own, so if the sender never completes the payjoin, the receiver can broadcast the original and still get paid.

Why it matters

BIP 78 names three heuristics payjoin defeats: common input ownership, spotting change by its script type, and spotting change by round amounts. Because payjoins look like normal payments, BIP 78 argues their existence makes these heuristics unreliable for everyone, not only for users. Receivers can also consolidate a UTXO in the same transaction, saving fees.

Async payjoin

BIP 78 requires the receiver to run an always-online HTTPS or onion endpoint. BIP 77, by Dan Gould and Yuval Kogman, proposes a version 2 in which an untrusted directory server relays encrypted messages over Oblivious HTTP, so sender and receiver don't need to be online at the same time.

Payjoin is a two-party form of CoinJoin. An earlier proposal with the same goal, Bustapay (BIP 79), did not use PSBTs.