BOLT 11 Invoicing

Published in

Coinmonks

4 min readMay 19, 2022

Invoice Protocol for Lightning Payments

What is a BOLT?

For different Lightning Network implementations like Core Lightning (formerly c-lightning), Eclair, LND, and others to interact seamlessly with each other, they need to agree on a specification. The BOLTs (Basis of Lightning Technology) are the documents that define the protocol specification for all Lightning implementations to communicate and interact.

What is a BOLT 11 Invoice?

Unlike the Bitcoin Network, where you generate an address and share it with the payer to send funds, the Lightning Network uses a different approach whereby the payer requests an invoice (also called a payment request) of a particular amount from the payee. The payment needs to be paid within a stipulated time since the Lightning invoice expires, and the same invoice should not be paid more than once because the first payment will have revealed the secret (preimage) to the participants in the payment route. The BOLT 11 invoice specifies what is needed for payment to be completed on the Lightning Network. Invoices are encoded using bech32 encoding, which is a checksum algorithm with the ability to detect errors. This is not the first use of this algorithm in the bitcoin space. The Bitcoin Improvement Protocol (BIP 173) also uses the same algorithm to encode an efficient Bitcoin address format.

My experience with BOLT 11 invoices

My first time implementing BOLT 11 for invoices was during the “Shock the Web” BOLT hackathon, where I and my team members needed to build a payroll system on Lightning Network. The system should be able to pay the employee’s node based on the schedule (hourly, daily, weekly, etc.) configured for the employee. Our solution LitBit requests the employee’s invoice.macaroon file and Node ID at the onboarding stage then uses the macaroon file to generate an invoice on behalf of the employee and settle the generated invoice automatically. This approach worked, but it requires the employer node to store the employee’s node details and credentials, which became a privacy issue. A better approach would be to use a Keysend, which is limited because there will be no proof of payment.

A deeper look at the BOLT 11 Invoice

Examining an invoice, you will notice it consists of different parts, which include the human-readable prefix (i.e., a portion human can glance at and extract information) and the data portion for encoding information required to complete payment. Below is a real invoice extracted from Mastering the Lightning Network

lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatfhq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9srp

The first four characters (lnbc) indicate the Lightning network (mainnet, testnet, etc.), followed by the amount, 2500, then “u” stands for micro bitcoin unit with a multiplier of 0.000001. The next portion of the data segment has 3 sections, namely: timestamp, tagged key-value pairs, and the signature of the entire invoice encoded using bech32 for good error correction.

BOLT 11 Invoice Shortcomings

One of the significant disadvantages of the invoicing approach is that the receiver always needs a medium or channel to speak with the payer for every invoice payment. This may be difficult or impossible in some situations, such as online donations when the receiver does not know who the sender is or even if there is one. Moreover, payment invoices contain information about the payee’s node, which has a negative effect on their privacy.

BOLT 11 has been improved

Despite BOLT 11 specifying how payment should be made with a payment invoice, it comes with some limitations, which led to BOLT 12 which is already implemented in Core Lightning. BOLT 12 uses “offer”, which can be static and reusable. Another enhancement to BOLT 11 is LNURL, which is a set of standards that codify some of these out-of-band interactions and standardize them so that wallets and other apps can implement them and be interoperable (according to advancingbitcoin.com blog).

Conclusion

A BOLT 11 invoice specifies what is needed to complete a payment on the Lightning Network. This invoice is constructed by the receiver and contains information such as the amount, unit of payment, node of the receiver, and so on. Some of this data is human-readable, while other fields are encoded with bech32. The fact that a communication channel needs to exist between the sender and receiver is a major challenge for a BOLT 11 invoice. There are alternatives to BOLT11 invoices, such as BOLT12 offers, LNURL, and Keysend.

I hope this helps understand the BOLT 11 Invoice. If you find this post useful, do share it with your friends on Facebook and Twitter!