The Recipient Puts In a Coin Too

Section 10 of the Bitcoin white paper, "Privacy", ends by admitting a limit.

Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.

The blockchain analysis industry turned that sentence into a rule. Assume all inputs of a transaction belong to one person, and use that assumption to bundle addresses into clusters, one cluster per owner. It is called the common-input-ownership heuristic.

Payjoin aims at the word "necessarily". The recipient of a payment adds one of their own coins as an input to that payment transaction. Now there are several inputs and two owners. From the outside it is one ordinary payment, and the analyst's assumption quietly fails.

What an Ordinary Payment Leaves Behind

In a UTXO wallet a payment usually looks like this. Alice sends Bob 0.05 BTC, and Alice's wallet holds a 0.08 BTC coin. The transaction has one input (0.08) and two outputs: 0.05 to Bob and 0.03 back to Alice as change. The numbers in this post leave out fees to keep the arithmetic simple.

An analyst looking at this transaction can guess several things. BIP-78 names three of them. The first is common input ownership, already mentioned. The second is address type: if all inputs come from addresses of one type, the output of the same type is probably change. The third is round amounts: an output that comes out even, like 0.05, is probably the payment, and the other one the change. In the transaction above, the third guess alone separates payment from change.

The Recipient Adds an Input

Make the same payment as a payjoin and Bob adds a 0.04 BTC coin from his own wallet as an input. The transaction becomes:

• Inputs: Alice's 0.08, Bob's 0.04
• Outputs: 0.09 to Bob, 0.03 to Alice

Bob received 0.05, merged it with his own 0.04, and now holds a single new 0.09 coin. Alice got 0.03 in change. What actually happened is exactly what happened before.

To the analyst it looks entirely different. Apply common input ownership and this is one person with 0.12 BTC making a payment. Look for the change, and the assumption that wallets do not pick more coins than they need kicks in. If the payment were 0.03, the 0.08 alone would have covered it, so there would be no reason to add the 0.04. The conclusion is that the payment was 0.09 and 0.03 was change. Both conclusions are wrong. The inputs belong to two people, and the real payment amount, 0.05, is written nowhere on the blockchain.

Had Bob chosen a different coin, things would change. If he had added a 0.01 BTC coin, the outputs would be 0.06 to Bob and 0.03 to Alice. This time, whichever output is the payment, Alice's 0.08 alone was enough. The 0.01 input looks like it went in for no reason, and an ordinary wallet does not make that choice. The transaction becomes a sign that someone added a coin. More on this below.

Bob gains something too. A recipient who takes many payments, such as a shop, piles up hundreds or thousands of small coins. Sooner or later they need a separate consolidation transaction to merge them, and that transaction pays fees while tying the shop's addresses together as one owner's. Receiving by payjoin merges one coin with each incoming payment, and most of that cost rides on a payment transaction that was going out anyway. BIP-78 lists this consolidation opportunity first among its motivations.

The Original Transaction as Collateral

For two people to build one transaction, they have to exchange information. The BIP-78 flow has four steps.

1. Bob shows a payment request (a BIP-21 URI) with a payjoin endpoint attached as the pj= parameter.
2. Alice builds her payment to Bob as usual and signs it completely. This is called the Original PSBT, and she sends it to the endpoint.
3. Bob adds his input to the original, adjusts his own output, signs only his own input, and sends it back. This is the Proposal PSBT.
4. Alice checks the proposal, signs her inputs again, and broadcasts.

The key safeguard is step 2. The original Alice sends first must be a complete transaction that could be broadcast as is. If Bob is a shop, the payment is secured the moment he receives it. If Alice disappears after step 3, Bob simply broadcasts the original. The original and the final transaction spend the same coins, so only one of them can make it into a block.

This collateral also protects Bob from another risk. A shop's endpoint is open to anyone. Someone with bad intent could send an original and never sign the final transaction, and each time Bob built a proposal he would reveal one of his coins. Repeat that, and the shop's wallet can be mapped coin by coin. BIP-78 calls this a UTXO probing attack. If the original must be a real, valid transaction, the attacker has to put a real payment on the line for every probe, and Bob can broadcast it and get paid. So BIP-78 requires receivers that take payments automatically to check that the original can actually be broadcast and to reject it if it contains inputs they have seen before. It also recommends reusing an already exposed coin for the next payjoin. The idea goes back to Bustapay (BIP-79), written by Ryan Havar in 2018, which required the sender to provide a fully valid, ready-to-propagate transaction first "to prevent costless spy/DoS attacks".

Alice's checks are long too. In the proposal Bob returns, she confirms that all her inputs are still there, that her outputs have not shrunk, that the total fee has not gone down from the original, and that the transaction version, nLockTime, and her inputs' sequence values are unchanged. Then she signs only her own inputs from the original. Bob, on the other hand, may change his own output freely, lowering its amount or swapping its address (output substitution). The point is that if Alice uses native SegWit and Bob's requested address is an older type, Bob can switch to the matching type and blur the second guess as well. If Bob runs the payjoin endpoint somewhere less trusted than the payment server, he adds pjos=0 to forbid substitution, so that even a compromised endpoint cannot redirect the payment.

BIP-78 also records its own weak spot. A hardware wallet cannot tell whether the original and the final transaction are two versions of the same payment. If the wallet software on the connected computer is compromised, the hardware wallet ends up signing two different transactions. Without payjoin, the most compromised software can divert is one payment. With payjoin it is two.

Looking Ordinary Is the Hard Part

Payjoin's whole value rests on looking ordinary. Only if it cannot be told apart from a normal payment does the analyst have to doubt every multi-input transaction. And looking ordinary is harder than it sounds.

The 0.01 example above is the classic case. In 2021 Simin Ghesmati and colleagues showed that payjoins can be exposed by the unnecessary input heuristic, which flags transactions containing inputs that look superfluous. If the receiver throws in just any coin, the payjoin becomes a marker instead of a disguise. rust-payjoin, a widely used implementation, has a selection function to avoid this. In a two-output transaction, it picks a coin such that, after it is added, the smallest input is larger than the smallest output. The smallest output then looks like ordinary change. The 0.04 in the example was exactly such a choice.

Fee rates leave traces as well. Wallets usually pay round fee rates such as 2 sat/vB. If the receiver adds an input and leaves the fee alone, the larger transaction drops to an awkward rate like 1.87. If removing one input and recalculating gives a round number again, suspicion becomes certainty. BIP-78 adds parameters through which the sender says in advance how much extra fee they will cover, so the receiver can restore the original rate.

Small differences between implementations become fingerprints too. In September 2025 a Sparrow user reported getting the error "The proposal PSBT changed the nLocktime" while paying a Cake Wallet payjoin. Sparrow was following BIP-78's checklist and rejecting a proposal whose nLockTime had changed. Cake Wallet, for its part, set nLockTime to 0 on every bitcoin transaction. Bitcoin Core and Electrum put in a value near the current block height, so a 0 alone told observers which wallet had built the transaction. Cake Wallet switched to Core's behaviour in August 2026. On the receiving side, the same wallet had for a while always contributed the first candidate coin, skipping the selection function above; that was fixed in June 2026.

Payjoin is a technique for imitating ordinary transactions. So the standard for "ordinary" is, in the end, the transactions other wallets actually produce.

What Stood in the Way Was the Server

The idea is old. In August 2018 Matthew Haywood summarized the conclusion of a community workshop on the Blockstream blog under the name P2EP (Pay-to-EndPoint), and in October Bustapay was assigned BIP-79. In May 2019 BIP-78, written by Nicolas Dorier of BTCPay Server, was assigned and replaced Bustapay. Among its reasons BIP-78 listed that Bustapay did not use PSBT, so a receiver wanting to bump the fee needed the full UTXO set. On April 16, 2020, BTCPay Server 1.0.4.0 shipped payjoin receiving for stores and sending from its built-in wallet. BIP-78's status today is "Deployed".

Payjoin still did not spread. The reason was not the math but the server. A BIP-78 receiver has to run a public HTTP endpoint protected by authenticated encryption (TLS or .onion), and has to be online at the same moment as the sender. That is easy for a shop server and practically impossible for a phone wallet. When an issue proposing payjoin was opened on Bitcoin Core in June 2020, its author noted that talking to the server might need OpenSSL and would likely face the same objections as BIP-70. Core had already removed the BIP-70 payment protocol, a TLS dependency being among the problems.

BIP-77 (Async Payjoin) targets that barrier. It was assigned in August 2023, authored by Dan Gould and Yuval Kogman. Instead of running a server, the receiver opens a temporary mailbox on an untrusted third-party directory server. The sender drops the original into that mailbox; the receiver comes by later, picks it up, and leaves the proposal in another mailbox. The two need not be online at the same time. The contents are encrypted end to end, so the directory cannot read the transaction. Requests pass through Oblivious HTTP (OHTTP, RFC 9458) relays so the directory does not learn which IP a request came from either. The cryptography is secp256k1 key exchange and ChaCha20-Poly1305, both already in Core for BIP-324 encrypted transport. No TLS is required.

The 2020 Core issue was closed on October 22, 2025. The same day Ava Chow, author of the PSBT specification BIP-174, opened a new tracking issue for bringing BIP-77 into the Core wallet. As of October 2026 that issue is open and the Core wallet has no payjoin yet. BIP-77 itself is still a "Draft". On the wallet side, the Bull Bitcoin mobile wallet added BIP-77 sending and receiving in 0.4.0 on December 27, 2024, and Cake Wallet followed in 4.28.0 on May 15, 2025. Sparrow supports BIP-78 sending, and a request for BIP-77 support has been open since March 2026.

For Those Who Never Use It

The effect payjoin aims for does not stay with its users. BIP-78 states that the mere existence of the proposal improves the privacy of people who do not use it, by making the common-input-ownership heuristic unreliable across the network. The moment an analyst has to suspect that some multi-input transactions belong to two people, every cluster built from multi-input transactions starts to wobble.

The effect is conditional, though. If payjoins are rare, an analyst can ignore the possibility and be right most of the time. And as shown above, an implementation that leaves traces gets its payjoins picked out instead of hidden. A CoinJoin is obvious to anyone, with its row of equal-value outputs, but it mixes many people. A payjoin mixes only two, but looks ordinary. The strength of the first is the size of the crowd it hides in; the strength of the second is the number of transactions it forces the analyst to doubt.

BIP-77 also points to uses beyond privacy. If an exchange deposit fills another customer's withdrawal in the same transaction, money that would be received and immediately sent on goes out in one transaction, saving block space and fees. It adds input batching to the output batching exchanges already do.

What You Can Try Now

A shop using BTCPay Server as the receiver can turn on payjoin receiving. If a payment request URI shows pj=, that shop accepts payjoin. A sender can paste that URI as is into a wallet with BIP-78 sending, such as Sparrow. For payments between individuals, both sides need a wallet with BIP-77 support (Bull Bitcoin, Cake Wallet). A wallet that does not know payjoin ignores the pj parameter and makes an ordinary payment, so a receiver loses nothing by turning payjoin on.

If you send from a hardware wallet, keep the two-signature risk described above in mind. If you receive, look at how your wallet picks the coin it adds. A wallet that adds just any coin does not hide a payjoin; it reveals one.

The white paper said multi-input transactions "necessarily" reveal that their inputs share an owner. In a payjoin, that sentence is wrong. And the only people who know the record differs from the facts are the two who made the transaction.