Bitcoin payments usually broadcast one signed transaction, which lets blockchain observers apply a simple rule: every input probably belongs to the same person. Payjoin, standardized in Bitcoin Improvement Proposal 78, breaks that common-input-ownership assumption by inviting the receiver to add its own inputs to the payment. The privacy benefit is real but conditional. A transaction only counts as a payjoin if the sender actually runs the protocol’s validation checklist, and a completed payment by itself proves nothing.
The negotiation starts with an original transaction. Under BIP78 the sender signs and finalizes a broadcastable transaction, packages it as a Partially Signed Bitcoin Transaction, or PSBT, and posts it to the receiver’s pj endpoint. That original must already be broadcastable, must carry witness or previous-transaction data for its inputs, and must leave out unnecessary extended public keys and key-path information. The receiver replies with a proposal PSBT that adds its own inputs and may adjust its own outputs.
BIP78 draws a sharp line around what the receiver may touch. The proposal must keep every original sender input and every original output that does not belong to the receiver, finalize only the receiver’s added inputs, and fill UTXO data only for those additions. It may add or replace receiver-owned outputs unless output substitution is disabled, but it must not reshuffle the existing inputs or outputs, and it must never lower the transaction’s absolute fee. Payment-output substitution is a separate permission: unless the sender forbids it with disableoutputsubstitution=true or the invoice signals pjos=0, the receiver may change its own payment output’s amount or script.
The sender’s job is to compare the proposal against the original, not merely to confirm that a readable PSBT arrived. The checklist is explicit: the absolute fee must be equal or higher, the transaction version and locktime must be unchanged, and each sender input’s sequence number must match. The proposal must contain no key paths and no partial signatures. Sender inputs must remain unfinalized so the sender can sign the modified transaction, while receiver-added inputs must be finalized with their UTXO data filled in.
Fee handling deserves its own scrutiny. A receiver may decrease a designated sender output to cover the extra weight of its added inputs, but only when both additionalfeeoutputindex and maxadditionalfeecontribution are valid, and the actual deduction is bounded three ways: by the sender’s stated maximum, by the increase in absolute fees, and by the original fee rate multiplied by the added-input weight. A contribution that fits under the headline maximum can still fail the other two tests.
The fallback is often misunderstood. A receiver may broadcast the original transaction after a timeout, and the original and the negotiated payjoin are competing spends that double-spend each other. After a timeout the correct move is to reconcile those two transactions, not to assume the payment vanished and send a fresh one. BIP78 also warns that a compromised sender wallet could trick a hardware signer into authorizing two separate payments, which is why the sender’s software, not the signing device alone, must enforce the checklist.
None of this makes payjoin privacy automatic. A valid signature, a successful payment, or a proposal that returns with no added inputs does not demonstrate that inputs were actually mixed. Treating a general privacy label as proof that each control ran is exactly the mistake the BIP78 specification is designed to prevent.
Adapted from BIP78 Payjoin: Receiver Permissions, Sender Checks and Fallback.