PayJoin: a payment that misleads analysis

When the receiver also adds a coin, a normal payment breaks the most-used heuristic.

The most-used assumption in chain analysis is that all inputs to a transaction belong to the payer. PayJoin breaks it with a simple trick: the receiver adds one of their own coins as an input.

How it works (BIP78)

  • The payer creates a normal signed transaction (a psbt) and sends it to the receiver's endpoint.
  • The receiver adds an input of their own and increases their output by the same amount.
  • The payer checks that they are not paying more than intended, then signs and broadcasts.

On-chain it looks like an ordinary payment. But the inputs come from two people, and the amounts no longer reveal the real payment.

Why it helps everyone

BIP78 notes that payjoin can invalidate the common-input, change-script-type and round-amount heuristics. Because payjoins look like normal transactions, the mere fact that they exist makes those heuristics less reliable for everyone, including those who never use payjoin.

Status

  • BIP78 has status "Deployed" and is supported by some wallets and payment servers (such as BTCPay Server).
  • BIP77 (Async Payjoin, status Draft) removes the need for the receiver to run a server that is online at the moment of payment.

Limit: both sides must use wallets that support it.