# Bitcoin Payjoin: a payment built with inputs from both sides 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki) Canonical: https://degreesofsatoshi.com/encyclopedia/bitcoin-payjoin/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:29:20.637Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Collaboration:** Both parties can contribute inputs ([A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki)) - **Privacy goal:** Weaken common-input ownership inference ([A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki)) - **Validation:** Check the proposal before final signing ([A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki)) ## 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki); [Partially Signed Bitcoin Transaction Format](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0174.mediawiki) ## 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki) ## 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki); [Some things you need to know](https://bitcoin.org/en/you-need-to-know) ## Questions ### 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki) ### 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. Evidence: [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki); [Transactions](https://developer.bitcoin.org/devguide/transactions.html) ## Claims and scope ### bitcoin-payjoin-quick-answer 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: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-payjoin-fact-collaboration Collaboration: Both parties can contribute inputs Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-payjoin-fact-privacy-goal Privacy goal: Weaken common-input ownership inference Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ### bitcoin-payjoin-fact-validation Validation: Check the proposal before final signing Scope: {"collection":"bitcoin","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [A Simple Payjoin Proposal](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0078.mediawiki) — Bitcoin 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. Retrieved: 2026-10-02T18:53:54.152Z. - [Partially Signed Bitcoin Transaction Format](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0174.mediawiki) — Bitcoin Improvement Proposals. Offline signing workflow, UTXO information and separate signing/finalization/broadcast steps. Locator: Roles; Creator; Signer; Transaction Extractor. Retrieved: 2026-10-02T18:53:54.151Z. - [Some things you need to know](https://bitcoin.org/en/you-need-to-know) — Bitcoin.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.609Z. - [Transactions](https://developer.bitcoin.org/devguide/transactions.html) — Bitcoin 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. Retrieved: 2026-10-02T18:53:53.759Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees 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/