Bolt-12 Proposal: Payment Protocol for Lightning Payments

Two weeks ago, Corné Plooy published a draft for a promising protocol improvement to Bolt-11 called Bolt-12: Payment Protocol For Lightning.

I was thinking of how to use Lightning for various types of payments, and I think it’s currently fine for customer/(web)shop type interactions, but it seems a bit inconvenient for other use cases, e.g. salary payments or direct pay-out of cryptocurrency bought on an exchange. I came up with an idea that addresses some of these issues and more (e.g. payee anonymity) by having a direct line of communication between payer and payee instead of BOLT11-style interaction

This BOLT specifies a protocol where the payee gives a payment URL to one or more potential payers. Payers can use the URL to open a communication channel to payee to request invoices. The same URL can be accessed multiple times and can be used by multiple payers for multiple payments. The URL will typically be short enough to fit in a QR code

As this BOLT relies on URLs, ZmnSCPxj pointed out the possibility to explore the work being done on the Web Payments Ecosystem currently led by the W3C Web Payments Working Group, and of which, Decker Christian of Blockstream is a member.

Possibly the Web Payments Working Group may provide better perspective on various other payment use cases as well as their subtleties, which can help inform your considerations in your proposed BOLT12.


An other interesting aspect of the BOLT-12 proposal is the anonymity feature built into the payment protocol. Quote:

In cases where anonymity of the payee has to be preserved, an URL scheme has to be used which protects this anonymity. An example of this would be an URL that points to a TOR hidden service.

In order to not reveal the payee node ID to the payer, payee can send an invoice to payer which has a partial onion route as destination instead of a node ID. The partial onion route ends at the payee, but it can start at some other node. All the payer has to do is prepend this partial route with extra hops, so that the complete route starts at the payer. Note that this makes the invoice considerably larger; this would have been infeasible in BOLT #11.

Similarly, allowing for much larger description fields than in BOLT #11 is not a problem anymore.

To allow for convenient and potentially anonymous refunds, the communication channel can be kept open, and the payer can send a refund invoice through the same communication channel.

Your editors will keep an eye on this exciting proposal.


Support us and the authors of this article by donating to the following address:


Comments powered by Talkyard.