P2EP (PayJoin)

3 min read

Pronunciation

[piː-tuː-iː-piː (ˈpeɪ-dʒɔɪn)]

Analogy

Think of PayJoin as two friends splitting a restaurant bill where they both put cash into the payment envelope. An outside observer watching the table might see the envelope being passed and money being placed inside, but can't determine who paid how much or even the total amount. Similarly, with traditional transactions, analysts can typically identify which addresses are sending and which are receiving. But with PayJoin, both the sender and recipient contribute to the inputs, making it impossible for observers to determine which coins actually changed ownership and which just moved between the recipient's own wallets. This collaborative breaks the pattern that chain analysis tools rely on, similar to how mixing cash from multiple people in a single payment confuses anyone trying to track individual spending habits.

Definition

A privacy technique where the recipient of a payment contributes their own inputs to the , breaking the common assumption in analysis that all inputs come from the same sender. P2EP (Pay-to-Endpoint, commonly known as PayJoin) enhances privacy by obscuring patterns, making it difficult for observers to determine actual payment amounts, and reducing the effectiveness of common chain analysis heuristics.

Key Points Intro

P2EP/PayJoin implements several key privacy enhancements for transactions.

Key Points

Common-input-ownership heuristic breaking: Invalidates the assumption that all inputs in a transaction belong to the same entity.

Payment amount obfuscation: Makes it difficult for observers to determine the actual value being transferred between parties.

UTXO consolidation camouflage: Disguises wallet consolidation activities as normal payments, reducing fingerprinting opportunities.

Blockchain footprint reduction: Decreases transaction size by combining what would otherwise be separate transactions from sender and recipient.

Example

Alice needs to pay Bob 0.5 BTC for consulting services. Instead of creating a standard where Alice's provides all inputs and sends 0.5 BTC to Bob with change returning to Alice, they use the PayJoin . Bob's first communicates its set to Alice through an encrypted channel. Alice's then constructs a special where her inputs contribute 0.5 BTC, but Bob also adds one of his existing UTXOs worth 0.3 BTC to the . The outputs include a 0.8 BTC payment to one of Bob's addresses (representing his original 0.3 BTC plus the 0.5 BTC payment) and change returning to Alice. From the 's perspective, this appears as a with inputs from multiple parties and doesn't look like a standard payment. Chain analysis tools can no longer reliably determine that exactly 0.5 BTC was transferred, as the movement of Bob's existing 0.3 BTC obscures the actual payment amount. This breaks multiple chain analysis heuristics while actually reducing the fee compared to two separate transactions.

Technical Deep Dive

P2EP/PayJoin implementations typically follow the BIP-78 standard, which defines both the construction and the secure communication between sender and receiver. The technical flow begins with the receiver generating a specialized BIP-21 URI that includes an endpoint for PayJoin negotiation. Communication occurs over an encrypted HTTPS channel using a server controlled by the recipient, though newer implementations employ nostr relays for serverless communication. The employs a two-round coordination process: First, the sender creates an original (without receiver inputs) and communicates this unsigned PSBT (Partially Signed ) to the receiver. The receiver then modifies this to include their own inputs and outputs while maintaining or increasing the payment value to themselves, returning the modified PSBT to the sender. For privacy preservation, implementations enforce several rules: the fee rate must remain consistent, output types must match input types to prevent script fingerprinting, and denomination patterns must be preserved to prevent amount correlation. Advanced implementations include coin selection algorithms specifically designed to maximize privacy by selecting receiver UTXOs that optimally confuse amount heuristics. To prevent probing attacks, servers typically implement defensive measures including request , filtering, and JoinMarket-style coordination to prevent information leakage about sets. For maximal privacy, most implementations recommend using PayJoin in conjunction with other privacy techniques including Tor routing and participation.

Security Warning

PayJoin requires direct communication between sender and receiver wallets, potentially leaking addresses or other identifying information if not implemented with additional network privacy layers like Tor. Always use PayJoin-compatible wallets with strong implementation of BIP-78 security standards.

Caveat

While PayJoin provides significant privacy benefits, it faces several adoption challenges including limited support and the requirement for receiver infrastructure to facilitate the interactive . The technique cannot be used for payments to parties not running PayJoin-compatible software, limiting its utility for everyday transactions with merchants or services not specifically supporting the . Additionally, PayJoin requires coordination between sender and receiver, making it unsuitable for non-interactive payments like donation addresses. While effective against current chain analysis heuristics, the technique may become less effective if widely adopted, as analysts could develop new heuristics specifically targeting PayJoin patterns. For maximum privacy, PayJoin should be used as part of a comprehensive privacy strategy rather than in isolation.

Related Terms

CoinJoin

UTXO

Blockchain & Cryptocurrency Glossary

P2EP (PayJoin) - Related Articles