Bitcoin Improvement Proposal 21 Eases User Experience When Paying Invoices

Different Bitcoin wallets have multiple options for whether to send an on-chain or a lightning payment which can be confusing to inexperienced users.

The below is a direct excerpt of Marty’s Bent Issue #1181: “BIP21 is a no brainer.“ Sign up for the newsletter here.

At the moment there is a massive UX hurdle that exists for users of different bitcoin wallet software providers.

One of the more illuminating talks at the Bitcoin Takeover event that was held at the Bitcoin Commons here in Austin last Friday was a panel discussion between Lisa Neigut (c-lightning, Blockstream), Rockstar Dev (Strike, which uses lnd), and Miles Suter (Cash App, which uses LDK) led by Matt Odell about the challenges of the interoperability between different implementations and overall UX when using the Lightning Network. During the discussion (which should be made public soon) the panel turned to the topic of BIP21, a BIP that I was unaware of but am very excited about after coming to understand it.

At the moment there is a massive UX hurdle that exists for users of different bitcoin wallet software providers. The UX around sending and receiving bitcoin transactions on-chain and via the Lightning Network. Some wallets are on-chain only, some are lighting only, and some allow users to use both but force you to manually shuffle between the two when sending and receiving. Enter BIP21, which aims to fix this UX hurdle by giving users optionality when sending. BIP21 would enable QR codes that enable wallet providers to include both a lightning invoice and an on-chain bitcoin wallet address in one place.

What is needed to push BIP21 forward as a standard is for more lightning network wallets to begin supporting it. Right now, when a bitcoin user using a BIP21 enabled wallet scans a QR code of a wallet that doesn’t have BIP21 enabled they receive an error code that can be confusing and leads to UX friction. If more lightning network wallets enable BIP21 and allow users who are only sending transactions on-chain to be provided with a fallback on-chain address it would bring an end to this UX friction. The best part is that BIP21 is backwards compatible, so there is no way in which it could disenfranchise the man in the coma who wakes up a decade from now and broadcasts a transaction from a wallet he hasn’t touched in many years.

Beyond this, BIP21 enables users the ability to make a conscious decision about whether they want to send via the protocol layer or the lightning network. If implemented, this should eliminate the need for different on-chain and LN UI tabs and make the transacting process much smoother between different wallets.

The first step toward realizing these benefits is making it so each wallet can read BIP21 QR codes. From there, each project can begin to create experiences that allow users to generate BIP21 payment codes. You must get wide support for scanning before it makes sense to get wide support for generating these payment codes. Here’s to hoping wallet providers make this a priority in the near future.