Author: Bitcoin Design
Payjoin refers to the collaboration between the sender and the receiver to jointly construct a Bitcoin transaction. As a powerful tool, Payjoin transactions can improve privacy for users, save fees, and integrate UTXO. However, due to its interactive and synchronous nature, Payjoin also faces some challenges and trade-offs.
Payjoin transactions can break some chain analysis heuristics during payment. However, constructing such transactions requires the sender and receiver to coordinate in real time through an endpoint.
This case study will:
- Clarify the motivations and goals of the sender and receiver.
- Analyze the Payjoin user experience (UX) of both parties of the transaction and propose corresponding design methods.
- Propose specific user flows and provide feasible design solutions whenever possible.
The core conclusion of this study is that although the initial setup is cumbersome for the recipient, each subsequent transaction requires almost no additional operations.
For the sender, there is almost no additional setup required except using a wallet that supports Payjoin. And, depending on their choice and the maturity of the specific implementation, the user experience can be exactly the same or almost the same as that of a normal transaction.
What is Payjoin?
In a Payjoin transaction, the sender and receiver will contribute inputs to the transaction in a collaborative way. The Payjoin mechanism is also called "Pay-to-Endpoint" (P2EP) because the entire collaborative process is coordinated by a network endpoint run by the receiver. The address of this endpoint will be passed along with the payment address and amount information through a BIP-21 format URI.
In the Payjoin process, both parties will edit, sign, and pass the transaction multiple times until the final version is confirmed before broadcasting. The BIP-78 proposal formally defines a protocol that includes two rounds of interaction (or one more round of interaction in addition to address sharing), as shown in the figure below.
background
This case study stems from a design challenge to design a sender payment flow based on Payjoin.
Payjoin presents unique challenges for real-time collaboration between transacting parties, and we need a completely new set of user flows to robustly and elegantly implement the features enabled by BIP-78 .
As of early 2023, Payjoin has not yet gained widespread adoption in the Bitcoin ecosystem.
Our Approach
The following steps were followed for this case study:
- Understand the user and technical requirements of both the sender and receiver.
- Investigate the implementation of Payjoin: BlueWallet (sender) and BTCPay Server (receiver)
- Based on the above research, design user flows for senders and receivers.
Understanding users and needs
Technically, anyone who transacts on the Bitcoin chain can use Payjoin. This case study categorizes users along two dimensions:
- Institutions (enterprises, exchanges, etc.) and individuals
- The sender and receiver of a payment
Receiver's goal
- Transaction privacy
- Save on handling fees
- Successful transactions
As a recipient, I want to:
- Create a Payjoin-enabled payment link and share it with the sender.
- Payjoin can be enabled for a wallet, account or user.
- Create a hot wallet and use it for Payjoin.
- Top up the newly created hot wallet so that it has UTXOs available for use.
- Connect an existing hot wallet to my Payjoin setup.
- Replenish the balance of the main wallet (watch wallet).
- Set up address replacement to replenish watch wallet balances or make unrelated payments.
- Monitor the status of Payjoin.
- Troubleshoot errors in the Payjoin process.
Sender's goal
- Transaction privacy
- Optimize transaction fees and control confirmation time
- Successful transaction
As the sender, I want to:
- Use Payjoin for private payments and break on-chain heuristics.
- You can choose whether to use Payjoin when making payment.
- Check the fees you will pay before your transaction is broadcast.
- Control the confirmation time of transactions.
- If the Payjoin process fails, the transaction can be aborted.
Sender Request
- An application that supports sending Payjoin
- Stay online throughout the Payjoin transaction
The sender obtains privacy protection through Payjoin, but usually needs to bear higher transaction fees.
Recipient Requirements
- Hot Wallet
- Hot wallet with funds
- An application that supports receiving Payjoin
- An endpoint that remains online for the duration of the transaction
The recipient is expected to receive the following benefits:
- Enhanced privacy of transactions
- Integrate UTXO collection
- Save transaction fees
Send Payjoin
For the sender, the process of participating in a Payjoin transaction is relatively simple. All you need to do is use a wallet that supports Payjoin and stay online during the transaction.
Research: Analyzing BlueWallet
We analyzed the Payjoin user flow that BlueWallet pioneered in 2020. See the research report for details.
The main findings are as follows:
- In the Payjoin transaction process, as the transaction volume increases, the actual fee rate will decrease, which may affect the estimated transaction confirmation time.
- The transaction generated by this process will have a fee rate that becomes an integer after removing an input, which may be a clue for on-chain analysis companies to identify Payjoin.
Payjoin sender process
We designed a new sender process to try to solve the above problems.
To create this flow, we assume that the receiver only provides UTXO and does not bear the transaction fee, as this makes the process simpler and more automated for both parties.
In short, the sender process we designed requires users to select a fee range instead of a specific fee amount (or rate), while the rest of the process is almost the same as a normal transaction. We use this design to set the three optional parameters specified in BIP-78 to build a simple and efficient Payjoin implementation.
See this document for detailed ideas.
The process can be viewed in this Figjam file . The detailed process and considerations are in this file .
Payjoin “Handshake”
We introduce the term “Payjoin Handshake” to succinctly describe the automated round-trip interaction between sender and receiver, where a PSBT that initially contains only the sender’s inputs is transformed into a final, signed, broadcastable transaction that contains inputs from both parties.
The above steps are not important for the users involved in the transaction, and no additional operations are required from either party. In layman's terms, the two parties do not even need to be aware of the process, as long as they stay online during the transaction.
Payjoin sender process prototype
Our goal is to make the user experience of this process as close to the normal process as possible. For those links that must be different, we will guide and help users through the UI.
Wallets that support Payjoin will display an interface with the feature enabled by default.
Users will see a fee range selection page that is very similar to the regular interface.
Next, the screen will display a transition interface, prompting the user that the Payjoin transaction is being built and signed.
After the Payjoin "handshake" is completed, you will enter the final check interface before the transaction is broadcast, which will display the final fee.
Finally, the payment success interface will inform the user that the Payjoin transaction has been successfully broadcast.
The detailed description of each interface can be found in this document . The design draft can be found in this Figma file .
Receive Payjoin
Based on the BIP78 protocol, the threshold for the receiver is much higher than that for the sender. The sender only needs a compatible mobile wallet, but the receiver cannot maintain an always-online endpoint with a mobile wallet alone. Enterprises and institutions face another dilemma: although they have the ability to easily deploy a Payjoin receiving solution, they are deterred by concerns about the security of hot wallets.
Although almost all mobile wallets are hot wallets and recharging them is simple, running a dedicated online server to perform Payjoin handshakes is technically and practically challenging. This is perhaps the biggest obstacle currently preventing Payjoin from gaining support and popularity.
Research: BTCPay Merchant/Receiver
The author successfully tested the Payjoin receiving function of BTCPay v1.7.12 in February 2023.
The main findings are as follows:
- Once setup is complete, a Payjoin-enabled link will be automatically generated.
- If a user chooses to add an existing hot wallet, BTCPay will not provide the option to enable Payjoin on the same page as when creating a new hot wallet.
- Whether in the settings for creating a new wallet or adding an existing wallet, if the user selects the watch (cold) wallet, they will never have access to the Payjoin functionality (since the process of signing a Payjoin transaction requires the use of a private key).
- Merchants can only connect to one Bitcoin wallet (unless through BTCPay Vault ), so if you use a cold wallet you cannot set up a hot wallet (and therefore cannot use Payjoin).
- If the balance in the hot wallet is not enough to execute the Payjoin transaction, BTCPay will not prompt or warn the user, resulting in payment failure.
- There is no dedicated place to manage and monitor Payjoin.
A full investigation of accepting Payjoin on BTCPay can be found in this analysis .
Recommended Receiver Process
Here, we will design a user flow for a point-of-sale (POS) system that is always online. This flow is not suitable for mobile wallets.
The receiver should be able to set up Payjoin during the initial configuration of the platform (app or POS system) or at any point afterwards. The following shows a standalone Payjoin setup process.
A detailed flowchart integrating the initial configuration process is available in this Figjam file .
Request Payjoin
Once the Payjoin setup is in effect, all payment requests (BIP-21 payment links or QR codes) should contain the information required to perform a Payjoin transaction (including the endpoint address) without requiring additional user action.
Payjoin Status/Settings
It would be a good idea to create a section in the settings page to provide a dedicated space for managing Payjoin settings and monitoring their status. This section can also provide a portal for users who use cold wallets to discover and set up the Payjoin function. This section can include the following content:
- Payjoin Setup Process
- Other Payjoin features, such as third-party endpoints, address/output replacement, replenishing cold wallet balances, etc.
- Monitor Payjoin readiness status: hot wallet status, Payjoin endpoint status, etc.
Insights
We learned a lot during the course of this case study, and the user flow we designed has applied many of those insights.
- Payjoin allows the receiver to consolidate UTXOs, which in the long run allows participants to pay lower fees. This is especially useful for exchanges, as they need this feature the most and have the technical capabilities to deploy a robust and reliable system.
- Considering that the transaction parties may need to go through several rounds of iterations and collaboration, this case study introduces the term “Payjoin handshake” to summarize all automated interactions between user operations.
- Maintaining an always-on endpoint seems to be the biggest obstacle to Payjoin implementation, and some alternatives are listed in the article.
- Although Payjoin places higher demands on the recipient, it also brings more benefits and opportunities.
- Output Replacement: This is a powerful idea from BIP-78. Although it is risky, it can also be a powerful helper for Payjoin users.
- Output substitution: Payjoin allows the recipient to publish static payment information, but use a different address when actually receiving the payment, avoiding address reuse.
- The Payjoin recipient does not need to set up an additional wallet and can directly use his daily consumption wallet as the hot wallet of Payjoin.
- Payjoin implementations need to be aware of the "round rate" analysis used to identify Payjoins, which should be handled automatically without user intervention.
New possibilities
Since it involves collaboration among multiple parties and many uncertain links (such as endpoints), both understanding and implementing Payjoin has a high threshold, but it also opens the door to a wide variety of new features and services.
Here are some examples:
- The recipient may choose to use a third-party endpoint (turning off address replacement), sacrificing some privacy in exchange for convenience.
- There is some exciting work going on around serverless Payjoin implementations, which would be a good fit for platforms that support both Bitcoin and Lightning.
- The implementation on the receiving end can use address replacement to allow users to initiate payments themselves.
- Payjoin collaboration can be performed via NFC (or other wireless near field communication technologies)
- BIP-78 can be used to add an extra round of interaction, allowing the sender to adjust the fee after the "handshake" and then send it back to the receiver for broadcast.
This case study delves into the design issues surrounding Payjoin in the hope of sparking community interest in its diverse use cases and potential value.
Acknowledgements :
- Thanks to Pavlenex of BTCPay for providing a BTCPay instance with Payjoin support, which we used to test the receiving process.
- Thanks to Nicolas Dorier for reviewing the content of this case study and actively participating in discussions on Payjoin.
- Finally, I would like to thank Dan Gould for his invaluable guidance, patience, and enthusiasm.
