Payjoin lets you prepare a Bitcoin payment together with its recipient. Both parties contribute their own funds to one transaction, while each keeps their private keys and authorizes spending their own money. This makes it harder for someone watching the public chain to infer who originally owned the coins involved. It creates neither a separate currency nor a guarantee of anonymity.
Alice is paying Bob. A wallet is an application or device for receiving and sending bitcoin. Her wallet does not hold a single bank-account balance: it selects unspent outputs from earlier transactions, called UTXOs. Each output has an amount and conditions for spending it. The new transaction refers to the UTXOs it spends through its inputs and creates new outputs for Bob and any change due to Alice. In an ordinary payment, only Alice supplies funds. With Payjoin, Bob takes part by adding a UTXO of his own. He still receives the agreed payment, while also moving some money he already owned. Both wallets must check the result. Each party then uses a digital signature to authorize spending their own inputs; they do not send each other private keys. A private key is a secret numerical value used to create such a signature. [1] [3] [8] [6]
An analyst often assumes that inputs spent together belong to one wallet. This is called the common-input-ownership heuristic. It is neither a Bitcoin rule nor proof of identity, just an inference based on usual behavior. Payjoin creates valid transactions where that inference fails. An observer cannot automatically assign every input to Alice. Other information, however, may still help. [1] [3]
We will express the amounts in sats, the smallest bitcoin units. Set fees aside briefly for clarity. Alice has a 100,000 sats input and pays Bob 20,000 sats, with 80,000 sats returning to her. Bob adds his own 50,000 sats input and his output increases to 70,000 sats. Total inputs and total outputs are still 150,000 sats each. Bob has not received an extra gift: he already owned 50,000 sats and gains only the agreed 20,000 sats. A real transaction must of course also pay a fee. [1] [6]
The wallets need a shared procedure and message format to work together. Nicolas Dorier’s BIP78, a technical document assigned its number in 2019, uses PSBT — Partially Signed Bitcoin Transaction. This is a data package containing a transaction and the information needed to check and sign it, rather than a payment already on the network. The payment request includes a pj parameter: the address of the service the wallet should contact. First, the sender supplies the original payment as a fully signed and finalized PSBT. It is ready to broadcast, despite the word “partially” in the format’s name. The recipient returns a revised proposal containing their added inputs and signatures. The sender checks it, signs their own inputs again and broadcasts the resulting transaction to the Bitcoin network. The connection must be encrypted and the other endpoint authenticated. A PSBT is not a wallet backup: neither the seed used to derive keys, nor private keys, nor unnecessary details of key derivation are sent. [1] [5]
The sender’s wallet must verify that its inputs and protected outputs remain, that change has not been reduced arbitrarily, and that the fee contribution stays within the permitted limit. It signs only its own original inputs. The protocol allows some changes to the recipient’s outputs under precise conditions; it is not permission to redirect the entire payment. On a signing device, users need to understand the displayed amounts, rather than merely approve another screen. [1] [5]
An added input uses space and can increase the absolute fee for that payment. Wallet negotiation determines who pays and up to what limit. The recipient may also consolidate UTXOs or include another payment they would otherwise make separately. Overall savings therefore depend on comparing the same operations, not a promise that every Payjoin is cheaper. The same fee in satoshis for a larger transaction means a lower feerate. [1] [2]
Under BIP78, the recipient needs an internet-accessible service and both parties communicate at the same time. That is inconvenient when a phone loses its connection. BIP77, or Payjoin v2, therefore uses a server as a temporary mailbox. One wallet leaves a message and the other collects it later, before the negotiation expires. This is asynchronous communication. The payment proposal itself is end-to-end encrypted: the participating wallets can read it, but the mailbox operator cannot. OHTTP, Oblivious HTTP, adds another layer of protection. Requests travel through a separate relay, so the mailbox server normally does not see the wallet’s network IP address. An IP address is the network address a device uses to communicate over the internet. Hiding that connection assumes the relay and server do not share their records. Neither receives private keys controlling bitcoins. The server can nevertheless delay or discard messages; encryption alone does not guarantee delivery. [2] [4] [7]
Payjoin does not automatically make a payment anonymous. Amounts, inputs, outputs and confirmation timing remain visible onchain. The other party also knows how your negotiation unfolded; a merchant may have an order bearing your name. The public transaction has no mandatory Payjoin label, but address reuse or wallet fingerprints can provide other clues. Automated recipients must also resist attempts to discover their UTXOs through requests that are never completed. [1] [2]
The original signed transaction can serve as an ordinary fallback payment. In the proper protocol it and the Payjoin proposal spend the same original inputs, so at most one can confirm. This is no reason to create another independent payment after an error without checking. A signature already provided can let the recipient broadcast the original transaction. The wallet should clearly show whether Payjoin, an ordinary fallback, or nothing yet has occurred, and reconcile that with the chain. [1] [2]
Sending and receiving Payjoin are different capabilities; the actual wallets and versions involved must work together. Merely processing a request without an added recipient input does not create the input-ownership benefit described here. When checked on 17 October 2026, BIP78 has Deployed status, while BIP77 by Dan Gould and Yuval Kogman is Draft. Payjoin is negotiated between applications using ordinary Bitcoin transactions: it does not wait for a Soft Fork or change issuance rules. [1] [2] [3]
For the clearest picture, read this entry together with CoinJoin, Bitcoin Privacy, PSBT, Pseudonymity, UTXO, Satoshi. The reverse links also lead from Change Address, Bitcoin Privacy, Pseudonymity, Chain Surveillance.