Encyclopedia Upgrades and scaling · Entry 224
Bitcoin Payjoin: a payment built with inputs from both sides
In this article
At a glance
Key facts
The receiver contributes to an ordinary on-chain payment
The BIP-78 flow begins with a payment request advertising a Payjoin endpoint. The sender provides an original payment in the partially signed transaction format, PSBT. The receiver returns a proposal with its own inputs and permitted output changes.
The sender must validate that proposal against the protocol’s checks before re-signing. A privacy label is not permission to accept arbitrary destinations or an uncontrolled fee increase.
A receiver can add value without changing the payment amount
Imagine the sender contributes 100,000 satoshis for a 50,000-satoshi purchase. The receiver adds its own 30,000-satoshi input. A simplified final transaction returns 49,000 to the sender, sends 80,000 to the receiver and pays a 1,000-satoshi fee. Total inputs and outputs plus fee both equal 130,000.
The receiver’s net gain is 80,000 minus its own 30,000 input: 50,000. Seeing both inputs in one transaction therefore does not prove they had one owner. The example illustrates accounting, not a complete protocol test vector.
Other information can still reveal the relationship
The transaction remains public. The parties know they transacted, and network observations, reused addresses or later spending can reveal additional links. Payjoin addresses particular transaction-analysis assumptions rather than erasing all evidence.
Both wallets need compatible support. BIP-78 describes one deployed proposal; later Payjoin protocols and wallet interfaces can have different negotiation and availability details.
Direct answers
Questions people ask
Does the receiver need to give the sender its private key?
No. Each participant signs for the inputs it controls. The collaboration exchanges transaction information and signatures, not a requirement to disclose private signing keys.
Is a Payjoin transaction a separate blockchain asset?
No. It is a Bitcoin transaction constructed collaboratively. The resulting inputs and outputs still follow Bitcoin’s normal validation rules.
Inspect the evidence
The answer and key facts have stable claim links. These records retain the scope and qualification when reused.
Payjoin lets a sender and receiver collaborate on one Bitcoin payment transaction, typically by adding receiver-controlled inputs alongside the sender’s inputs. That makes the usual assumption that every input belongs to one owner unreliable. In BIP-78, the parties exchange transaction proposals and the sender validates the result before signing and broadcasting. It improves a particular privacy property; it does not make the payment invisible or guarantee anonymity.
Educational explanation. Product-specific behavior is scoped to the cited documentation, checked 2026-10-02.
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimCollaboration: Both parties can contribute inputs
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimPrivacy goal: Weaken common-input ownership inference
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimValidation: Check the proposal before final signing
Scope: Bitcoin · data through 2026-10-02. Verification: verified · 2026-10-02T19:29:20.637Z.
Link to this claimRevision history
- — First publication after primary-source research and separate automated verification.
Source register
Sources and references
Retrieval dates and locators are recorded individually.- A Simple Payjoin ProposalBitcoin Improvement Proposals
Receiver-input payment proposal and required output/fee validation in BIP-78.
Locator: Motivation; Protocol; Receiver's original PSBT checklist; Sender's payjoin proposal checklist · Version / scope: Pinned BIPs revision · Retrieved: 2026-10-02T18:53:54.152ZOpen source - Partially Signed Bitcoin Transaction FormatBitcoin Improvement Proposals
Offline signing workflow, UTXO information and separate signing/finalization/broadcast steps.
Locator: Roles; Creator; Signer; Transaction Extractor · Version / scope: Pinned BIPs revision · Retrieved: 2026-10-02T18:53:54.151ZOpen source - Some things you need to knowBitcoin.org
Payment reversibility, confirmation risk and visible transaction records.
Locator: Bitcoin payments are irreversible; Unconfirmed transactions aren't secure; You are your own bank; Bitcoin is not anonymous · Retrieved: 2026-10-02T18:53:53.609ZOpen source - TransactionsBitcoin developer documentation
Inputs, outputs, authorization, change, coinbase exceptions and fee accounting.
Locator: Introduction; Spending An Output; P2PKH Script Validation; Multisig; Transaction Fees And Change; Avoiding Key Reuse · Version / scope: Developer guide; historical implementation details require qualification · Retrieved: 2026-10-02T18:53:53.759ZOpen source
Research and drafting use AI assistance. A separate automated review checks claims against primary sources; no external expert or named human review is implied. Publication, substantive editing, source retrieval and verification are recorded separately. This version was independently checked by an automated reviewer on 2 October 2026.
Editorial method and correctionsDegrees of Satoshi editorial project. “Bitcoin Payjoin: a payment built with inputs from both sides.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/bitcoin-payjoin/