Better Bitcoin Transactions
A simple protocol that can preserve privacy, scale Bitcoin, and save fees, without changing how you use it.
Help improve Bitcoin by asking your wallet to implement payjoin!
Why Payjoin?
The Problem
Satoshi said that transactions with multiple inputs "necessarily reveal that their inputs were owned by the same owner" in the bitcoin whitepaper. For legacy bitcoin software, this tends to be true. As a result, you end up spending more than you have to and surveillance companies use this revelation to creep on bitcoin users.
Privacy
Transaction histories are normally easy to trace, allowing chain surveillance companies to spy on bitcoin users.
Scaling
Bitcoin’s blockchain processes about 7 transactions per second, as block space is scarce.
Fees
Normally, one fee is paid for a single transaction, which frequently fluctuates based on demand and is often untenable for small purchases.
The Solution
Payjoin joins sender and receiver inputs in one transaction. Batching like this reduces fees and packs more payment activity, scaling bitcoin. Joining inputs from many owners breaks that assumption Satoshi warned us about. Your wallet can payjoin when you spend without having you make any decisions. And if your wallet doesn't support it, it has a seamless fallback inside of the BIP 21 unified payment standard .
Privacy Enhanced
By cleverly taking advantage of transaction structure, payjoin allows for enhanced privacy for everyone ― even for those who don’t use it ― foiling chain surveillance.
Scaling Upgraded
Payjoin settles many transfers together in one transaction, saving time spent waiting for block confirmations and enabling higher throughput.
Fees Saved
As a byproduct of the scaling improvements, the many transfers inside each payjoin share the fees of a single transaction.
Lightning Compatible
Open all your channels at once
Combining payjoin with the Lightning Network opens up new possibilities for bitcoin.
With payjoin, lightning nodes could:
- Fund and open any number of channels in one transaction
- Auto-open new channels when transactions are sent to them
Payjoin User Experience
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.
As you can see, Bob's wallet automatically payjoined. Neither he nor the merchant had to do anything, and their privacy was preserved. It's that easy.
Therefore, the biggest barrier to payjoin adoption is not UX, but wallet integration
How is it private?
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 input 1: 1,797,496 sats 🔀 output 0: 288,535 sats output 1: 1,705,291 sats Because of payjoin, any of the following outcomes are plausible:
- Alice had input 0 and input 1.
She paid Bob output 0 and made output 1 as change - Alice had input 0 and input 1.
She paid Bob output 1 and made output 0 as change - Bob had input 0, Alice had input 1.
Bob was paid 90,326 sats to output 0, Alice took output 1 as change. - Bob had input 0, Alice had input 1.
Bob was paid 1,507,082 sats to output 1, Alice took output 0 as change.
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.
Use Payjoin with your Stack
Send Payjoin
Receive Payjoin
Sending payjoin is simple compared to lightning. It works anywhere with internet:
Requesting payjoin requires a hot wallet and a public https:// or .onion server endpoint:
- HTTP request a payjoin by sending a fallback transaction to the unified URI
- Sign and broadcast the payjoin transaction response
- Enjoy privacy and know you helped the whole network
- Share a payjoin URI or QR code
- Listen for a payjoin request
- Respond with a payjoin proposal, having added receiver input
- Wait for the sender to broadcast the transaction
Make sure your front end accepts bip21 payjoin uris. There are a huge number of reasons they improve your users’ experience anyhow.
Payjoin is a great fit for lightning nodes since they already depend on hot wallets on always-online servers.
Supporting Wallets
A list of wallets that support sending or receiving payjoin. We need your help growing this list!
Future Plans
Serverless Payjoin
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.
Async Payjoin
The “hot wallet” limitation may also be removed with an asynchronous payjoin protocol that lets the sender and receiver wait to receive signatures.
We need your help!
Payjoin has many benefits for Bitcoin and doesn't require much, we need your help to get wallets to support it!
- Developer: Check out Payjoin Dev Kit (PDK)
- Designer: See the Figma
- Anyone Else: Ask your wallet provider to integrate it !
