-
@ DeSign_r
2025-05-16 07:51:08Payjoin allows the sender and receiver of an on-chain payment to collaborate and create a transaction that breaks on-chain heuristics, allowing a more private transaction with ambiguous payment amount and UTXO ownership. Additionally, it can also be used for UTXO consolidation (receiver saves future fees) and batching payments (receiver can make payment(s) of their own in the process of receiving one), also known as transaction cut-through. Other than improved privacy, the rest of the benefits are typically applicable to the receiver, not the sender.
BIP-78 was the original payjoin protocol that required the receiver to run a endpoint/server (always online) in order to mediate the payjoin process. Payjoin adoption has remained pretty low, something attributed to the server & perpetual online-ness requirement. This is the motivation for payjoin v2.
The purpose of the one-pager is to analyse the protocol, and highlight the UX issues or tradeoffs it entails, so that the payjoin user flows can be appropriately designed and the tradeoffs likewise communicated. A further document on UX solutions might be needed to identify solutions and opportunities
The following observations are generally limited to individual users transacting through their mobile devices:
While users naturally want better privacy and fee-savings, they also want to minimise friction and minimise (optimise) payment time. These are universal and more immediate needs since they deal with the user experience.
Added manual steps
TL;DR v2 payjoin eliminates server & simultaneous user-liveness requirements (increasing TAM, and opportunities to payjoin, as a result) by adding manual steps.
Usually, the extent of the receiver's involvement in the transaction process is limited to sharing their address with the sender. Once they share the address/URI, they can basically forget about it. In the target scenario for v2 payjoin, the receiver must come online again (except they have no way of knowing "when") to contribute input(s) and sign the PSBT. This can be unexpected, unintuitive and a bit of a hassle.
Usually (and even with payjoin v1), the sender crafts and broadcasts the transaction in one go; meaning the user's job is done within a few seconds/minutes. With payjoin v2, they must share the original-PSBT with the receiver, and then wait for them to do their part. Once the the receiver has done that, the sender must come online to review the transaction, sign it & broadcast.
In summary,
In payjoin v1, step 3 is automated and instant, so delay 2, 3 =~ 0. As the user experiences it, the process is completed in a single session, akin to a non-payjoin transaction.
With payjoin v2, Steps 2 & 3 in the above diagram are widely spread and noticeable. These manual steps are separated by uncertain delays (more on that below) when compared to a non-payjoin transaction.
Delays
We've established that both senders and receivers must take extra manual steps to execute a payoin transaction. With payjoin v2, this process gets split into multiple sessions, since the sender and receiver are not like to be online simultaneously.
Delay 2 & 3 (see diagram above) are uncertain in nature. Most users do not open their bitcoin wallets for days or weeks! The receiver must come online before the timeout hits in order for the payjoin process to work, otherwise time is just wasted with no benefit. UX or technical solutions are needed to minimise these delays.
Delays might be exacerbated if the setup is based on hardware wallet and/or uses multisig.
Notifications or background processes
There is one major problem when we say "the user must come online to..." but in reality the user has no way of knowing there is a payjoin PSBT waiting for them. After a PSBT is sent to the relay, the opposite user would only find out about it whenever they happen to come online. Notifications and background sync processes might be necessary to minimise delays. This is absolutely essential to avert timeouts in addition to saving valuable time. Another risk is phantom payjoin stuff after the timeout is expired if receiver-side does not know it has.
Fee Savings
The following observations might be generally applicable for both original and this v2 payjoin version. Fee-savings with payjoin is a tricky topic. Of course, overall a payjoin transaction is always cheaper than 2 separate transactions, since they get to share the overhead.
Additionally, without the receiver contributing to fees, the chosen fee rate of the PSBT (at the beginning) drops, and can lead to slower confirmation. From another perspective, a sender paying with payjoin pays higher fees for similar confirmation target. This has been observed in a production wallet years back. Given that total transaction time can extend to days, the fee environment itself might change, and all this must be considered when designing the UX.
Of course, there is nothing stopping the receiver from contributing to fees, but this idea is likely entirely novel to the bitcoin ecosystem (perhaps payments ecosystem in general) and the user base. Additionally, nominally it involves the user paying fees and tolerating delays just to receive bitcoin. Without explicit incentives/features that encourage receivers to participate, payjoining might seem like an unncessary hassle.
Overall, it seems that payjoin makes UX significant tradeoffs for important privacy (and potential fee-saving) benefits. This means that the UX might have to do significant heavy-lifting, to ensure that users are not surprised, confused or frustrated when they try to transact on-chain in a privacy-friendly feature. Good, timely communication, new features for consolidation & txn-cutthrough and guided user flows seem crucial to ensure payjoin adoption and for help make on-chain privacy a reality for users.
---------------
Original document available here. Reach out at
yashrajdca@proton.me,y_a_s_h_r_a_j.70on Signal, or on reach out in Bitcoin Design discord.https://stacker.news/items/981388