Shoehorning new features into existing on-chain UX (sucks)
Payjoin exposes this; silent payments fixes it
A guest article from Yashraj
Bitcoin’s blockchain is transparent. Activity around any on-chain address is easy to inspect by using free, publicly-available blockchain explorers. As a result, existing on-chain transaction UX in privacy-conscious wallets revolves around one major concern: avoiding address reuse. This pre-occupation has given rise to certain UX patterns that are standard in practically every self-custody wallet. Issuing (and communicating) new addresses for every transaction is inefficient and unintuitive. Users adapt to this routine over time, but the friction is significant. This friction becomes apparent when you consider steps taken outside of the wallet app itself.
Let’s walk through the steps new addresses require.
the receiver must 1) open their wallet app 2) click on Receive button 3) copy the on-chain address 4) share it with the sender.
the sender must 1) ask the receiver for a fresh address, 2) obtain it from the receiver, then 3) enter this address into their wallet’s Send page (and construct the transaction) and 4) briefly review it before broadcast
These steps are repeated for every single payment. Contrast this with other payment or communication protocols we use: email addresses, phone numbers and bank account information – you exchange this information once, and can use it repeatedly.
Bitcoin should be similarly easier to use, while still preserving privacy. New protocols like silent payments and payjoin provide an opportunity to re-examine (and maybe improve) on-chain transaction UX. In this post, we will do just that.
Enter silent payments
We discussed how avoiding address reuse is the basis for existing on-chain transaction UX. For example, a prominent Receive button allows the user to generate new on-chain addresses with each use. Send flows involve (and often start with) entering the recipient’s address.
Silent payments is a protocol that was created to prevent address reuse. It gives us a new type of address that never appears on-chain, but is used by the wallet app to programmatically derive unique on-chain addresses during the transaction process. Silent payment addresses are meant to be reused. As many times as needed.
The 4 step process (as a recipient) to simply share a fresh address with the sender? Gone. Share your silent payment address once, and you’re done! Remember asking the receiver for a fresh address every single time you want to pay them? No more; just get their silent payment address once, and save it for future use. Silent payments is Efficiency Go Up technology!
Not just that, silent payments (along with BOLT 12 and BIP-353) make using bitcoin as easy as sending an email or making a phone call. With silent payments, wallet apps can provide Contacts functionality to its users, storing this reusable payment information. Adding a Contacts module allows applications to tap into a highly intuitive, long-established user pattern, while ensuring address re-use is prevented. Apps like Phoenix have already started doing this for BOLT 12 offers.
Of-course, silent payments can also fit into existing send flows, as existing implementations have done. But in this author’s view, existing user flows don’t do justice to silent payments... and to users frankly.
One-shot payment flow…
In spite of the cumbersome user steps described at the beginning of this post, one feature of the existing interaction model is that users are able to complete their actions within a single sitting.
After the receiver has shared their address, they are not required to do anything further. They never have to sign or review anything. This is a logical and familiar experience for the recipient of the payment.
The sender only comes online after they’ve received the address from the recipient. They are able to construct, review and broadcast the transaction in a single session too, usually taking less than a minute.
A one-shot payment flow. Nice. Except payjoin disrupts it!
Enter payjoin
Matters get more complicated when it comes to payjoin. In payjoin, both the sender and the receiver work together to construct a privacy-friendly transaction (see why). To do so, they pass around transaction drafts, to which each party adds their coins and signatures. With async payjoin, this procedure can be done without either party having to run a server (to facilitate this coordination), or both parties needing to be online at the same time. Elimination of these constraints puts privacy within the reach of non-technical users, while also allowing it to be used in a wider set of scenarios.
For e.g. Alice and Bob decide to go to a bitcoin conference in Las Vegas for the first time. Alice buys the flight tickets for both of them. Bob has recently orange-pilled her, so she agrees to be paid back in bitcoin. Alice opens her bitcoin wallet and shares an invoice with Bob over chat. By the time he’s online to act on it, she’s on a flight. With async payjoin, they can still do a privacy-friendly transaction.
However, async payjoin comes with tradeoffs, specifically extra steps and potential delays. I wrote about this in my post about payjoin UX challenges.
Long story short, async payjoin adds bells & whistles to the process of sending or receiving bitcoin, such as:
receivers need tomust come online in the middle of the payjoin process
receivers may have to pay fees
senders must sign twice (once for initial draft, once after receiver adds their inputs), and come online to do so
both parties must wait for each other to come online and sign
this process (likely) spans multiple sessions for each user – breaking the one-shot payment flow
These situations don’t fit very well within existing send/receive flows. Additionally, the above points are unlikely to be obvious to anyone, but the most tech-savvy users. The application must inform, assist or encourage users about these aspects. Payjoin transactions not only include additional manual steps, their async nature also means they might take a long time (hours) to execute. Where hardware signers and/or multi-sig setups are involved, the effort or just the situation might make it too onerous for the user to pursue a payjoin transaction. This highlights the need to help users form an appropriate mental model for payjoin, complete with optionality, feedback and suitable communication through the UI.
Furthermore, payjoin enables features (such as payment batching and timelock refresh) that might not fit into existing user flows.
Overall, it seems clear that new UI and user flows are needed for good UX and full-featured payjoin implementations. Shoehorning payjoin into existing UX seems barely possible and not desirable.
Wrapping up
Many consider bitcoin hard to use. The existing on-chain send/receive flows lend credence to this view, as we saw above. Silent payments can change this perception by helping match on-chain UX with that of email or fiat fintech by using a safely reusable payment method, transforming on-chain UX in the process.
Privacy is another area that’s not a strong suit for bitcoin. Payjoin addresses this, helping users to protect their privacy during the course of making/receiving a payment. However, as discussed above, async payjoin does not play well with prevailing on-chain UX.
The writing is on the wall – existing transaction UX leaves a lot to be desired. It’s time to move past it.