Payjoin brings privacy to bitcoin without changing the way you’re used to using it. Payjoin transactions don’t look any different from normal activity so they boost everyone’s privacy, even those who don’t payjoin, and foil chain surveillance.
Payjoin is easy to integrate, but can only take off when software supports sending and receiving via the BIP 78 standard.
Satoshi said that transactions with multiple inputs “necessarily reveal that their inputs were owned by the same owner” in the bitcoin whitepaper. That assumes transactions only have one funding source.
This assumption is the basis of bitcoin surveillance.
Payjoin lets us build transactions with inputs from another owner that break that “common ownership assumption.” It works as a default for wallets that support it because it has a seamless fallback inside of the BIP 21 unified payment standard.
This is a BIP21 unified URI with a payjoin parameter. Even if a wallet does not support payjoin, it can still fall back to the address to make a successful transfer.
Raw Data
bitcoin:BC1Q74ACVCYYUMNY0PR9M676WXRVRYQUC86J3T7G6P?amount=0.0006942&pj=https://do.payjoin.org
This particular BIP21 will go to to payjoin.org’s cold wallet. By using payjoin, you can get a unique address for your support to keep that private. Yes, even though we use a cold wallet. Cool ❄️!
When using the code above, a successful payjoin will replace the BIP21 address with a substitute unique to your transfer. Both sender and receiver get enhanced privacy since nobody else knows about the substitue address. If someone looks up the address from the code above, they will not find the payjoin. In this way, it protects privacy like a static payment code or a stealth address.
Let’s check out a payjoin flow. Bob is on the left trying to purchase some jewelry without his peers finding out. The merchant’s point of sale is on the right. Click Bob’s screen to scan the QR code and see just how easy it is to payjoin.
The following transaction conforms to unnecessary input heuristic. It contributes more inputs than are typical for the outputs it produces. It could be a payjoin, but we can’t know for sure.
It’s normal to make transactions like this to minimize future fees by merging coins. Merging coins connects their histories and hurts privacy if this is not a payjoin.
By using payjoin, two parties come together to merge coins, save fees, and enhance privacy at the same time.
input 0: 198,209 sats output 0: 288,535 sats
🔀
input 1: 1,797,496 sats output 1: 1,705,291 sats
Because of payjoin, any of the following outcomes are plausible:
The possibility of that Alice and Bob may have both contributed via payjoin breaks the heuristic analysis used to harm bitcoin privacy. Payjoin not only makes it more difficult for someone looking at payjoin user history to figure out exactly how much money changed hands, it does so for every other transaction with many inputs and two outputs too. It looks no different.
Sending payjoin is simple compared to lightning. It works anywhere with internet:
Make sure your front end accepts bip21 payjoin uris. There are a huge number of reasons they improve your users’ experience anyhow.
Requesting payjoin requires a hot wallet and a public https://
or .onion
server endpoint.
Payjoin is a great fit for lightning nodes since they already depend on hot wallets on always-online servers.
There is a public proposal to allow anyone to receive a payjoin without running a public server. In order to advance Serverless Payjoin into a formal BIP specification we need your help with a second, independent implementation. Please share, leave your comments, and join the development chat to help.
The “hot wallet” limitation may also be removed with an asynchronous payjoin protocol that lets the sender and receiver wait to receive signatures.