Author: Dan Gould
Source: https://payjoindevkit.org/2025/03/31/payjoin-probing-attacks/
The following content provides the ultimate solution to UTXO probing attacks surrounding Payjoin, clarifies the effectiveness of current mitigation measures, and offers a decisive argument for Payjoin adoption. Payjoin, as a foundational interactive transaction batching protocol, saves transaction fees by reducing the actual transfer size and enhances privacy by disrupting blockchain monitoring analysis. Although probing attacks exist theoretically, their implementation is costly, has been mitigated in practice, and does not pose a substantial obstacle to Payjoin adoption.
Probing Attack Analysis
In a probing attack, the attacker initiates a Payjoin and then deliberately terminates it to learn about the recipient's wallet UTXOs. Since the Payjoin recipient replies to the potential sender with a Payjoin proposal containing their UTXOs, the sender gains information about these UTXOs. If obtaining a Payjoin proposal comes at no cost, this attack would provide the attacker with new information about the recipient that they would not have otherwise obtained.
The earliest Payjoin specifications outlined measures for handling such attacks, as detailed in the relevant sections of BIP 79 and BIP 78.
Current Mitigation Measures
Minimum Value Strategy
The minimum value strategy sets a floor price where the recipient only responds with a Payjoin proposal containing their UTXOs if the transaction value exceeds this base price.
Minimum Fee Rate
The recipient can choose to respond only to senders whose "fallback transaction" fee rate exceeds a certain threshold. If the sender terminates the transaction, the recipient can broadcast the fallback transaction, causing the sender to lose the fees paid for the transaction.
Minimum Transfer Amount
The recipient can choose to respond only to senders with a payment to themselves exceeding a certain value. If the sender terminates the transaction, the recipient can broadcast the fallback transaction, which will cause the sender to lose their transfer amount plus fees.
Fallback Transaction Broadcast
Payment processors as Payjoin recipients should be most concerned about probing attacks, as they automatically respond to Payjoin creation requests. Manual recipients must generate requests for each potential probe, making repeated attack requests problematic because the recipient will inevitably recognize multiple initiated and terminated requests.
According to the specification, automated payment processors as Payjoin recipients must broadcast the sender's valid fallback transaction if they do not see the Payjoin transaction broadcast after expiration timeout. This inherently enforces a minimum relay fee rate strategy.
This mechanism can also be implemented by manual peer-to-peer recipients as an additional preventive measure. After an appropriate time (e.g., after an asynchronous Payjoin session expires), the fallback transaction can be manually or automatically triggered for broadcast.
Input Replay
Automated payment processors should provide their inputs based on the fallback transaction's inputs when responding to the sender's request; always responding with the same inputs for the same sender inputs. This ensures the implementation of the minimum cost set by the mitigation measures.
Session Policy Binding
In asynchronous Payjoin sessions, receiving sessions are bound to the Bitcoin URI used to request them. The recipient can bind specific policies to a particular URI for a specific sender based on their trust level.
Refuting Core Concerns
Claim: Probing attacks have no cost
Fact: When the fallback transaction is broadcast, the attacker must pay fees and risk paying the minimum value to the recipient.
Claim: Current mitigation measures are ineffective
Fact: Proper implementation strictly limits information leakage and significantly increases the attacker's costs. No reports of probing attack abuse currently exist.
Claim: Attackers can always spend enough resources to probe
Fact: Theoretically, active attackers can always attack privacy (e.g., dust attacks, Sybil attacks), but Payjoin forces attacks to shift from passive (low-cost, scalable) to active (high-cost, detectable).
Claim: Payjoin should be completely avoided for security
Fact: Without Payjoin, information passively leaked during regular fund consolidation processes is more extensive than information actively leaked during probing attacks. Payjoin significantly reduces overall information leakage, even for those not using the protocol. Imagine a world without Payjoin: once your UTXOs are consolidated, people who have sent Bitcoin to you will likely know your other UTXOs. Because without Payjoin, the "input common origin" assumption will hold.
Claim: Payjoin does not allow UTXO selection, which could have prevented leakage
Fact: Payjoin is a peer-to-peer batching mechanism. Payjoin participants can choose to use any UTXOs based on local tags or any other preference. However, even complete tag information is typically insufficient to protect user activity privacy. UTXO selection is an unrelated issue.
How Payjoin Prevents Leakage
- Breaking Input Source Correlation Clues: Breaking the Satoshi assumption that all inputs come from the same sender.
- Interfering with Change Detection: Making it more difficult to determine which output is the payment and which is the change.
- Eliminating Separate Fund Consolidation: Receivers will batch merge received payments, making the cost of breaking trace analysis lower than doing nothing (which would leak information).
- Improving Overall Privacy: Payjoin transactions can be indistinguishable from non-Payjoin transactions, multiplying the difficulty of monitoring.
Edge Cases and Real-World Scenarios
Theoretically, attacks exist, especially when implementation guidelines are not followed. Such situations are implementation issues, not flaws in the Payjoin protocol itself. The "Payjoin Dev Kit" guidance can help avoid implementer abuse as much as possible.
Although subtle attacks like dust attacks do occur on BTC, large-scale Payjoin probing is costly and practically limited.
How to Protect Your Payjoin Implementation
- Use the Payjoin Dev Kit to follow best practices by default.
- For custom implementations, follow the BIP guidelines and mitigation list in this article.
- Seek help from the Payjoin Dev Kit team to ensure your implementation takes appropriate protective measures, such as requesting persistence and fallback transaction broadcasting.
Why Payjoin Stands Out
The economic and privacy advantages of Payjoin far outweigh the risks of theoretical probing attacks. Its adoption benefits the entire BTC network, as higher Payjoin usage can even improve the privacy of non-Payjoin transactions. The Payjoin Dev Kit integrates best practices to address known probing attacks, significantly improving the situation for Payjoin receivers.
(End)
