Lightning Network

What Is the Lightning Network?¶

The Lightning Network (LN) is an L2 payment protocol built on top of Bitcoin. It is designed to enable fast transactions between participating nodes and has been proposed as a solution to Bitcoin's scalability challenges. The system is peer-to-peer and enables cryptocurrency micropayments through a network of bidirectional payment channels without the need for custodial intermediaries.

The main implementation of the Lightning Network involves two payment parties establishing an off-chain "channel," through which they can make multiple payment transactions. When settlement is needed, the channel is closed. When there is no direct channel between the two parties, a third-party node can be used as a relay.

Advantages and Disadvantages of the Lightning Network¶

Compared to on-chain Bitcoin transactions, the Lightning Network offers several advantages:

Lower transaction fees, very friendly for small payments: Since on-chain Bitcoin transactions require users to competitively bid against each other, a single transaction fee typically costs several dollars, and during peak periods can reach tens of dollars. For small transactions, the fees often exceed the amount being transferred. Lightning Network channel fees are dynamic and typically charged at a few basis points of the BTC amount transferred.
Under the Lightning Network protocol, there is no fundamental limit on the number of payments that can occur per second, constrained only by the capacity and speed of each node.
Better privacy: The details of Lightning Network payments are not publicly recorded on the blockchain. Lightning Network payments can be routed through many successive channels, and while each node operator can see payments passing through their channel, if they are not adjacent, they cannot see the source or destination of the funds.

At the same time, the Lightning Network also has some limitations:

The Lightning Network requires nodes to remain online at all times to serve as payment channels, making them relatively vulnerable to hacking and theft.
Multiple users may rely on a critical hub node, and such a hub going offline can quickly lead to a collective (or complete) network collapse.

LNURL¶

LNURL is a stack of simple protocols designed to coordinate the information needed to complete payments on the Lightning Network via HTTP.

The three core components of the LNURL protocol are: an authentication scheme that allows users to log into services using a public key, an invoice request scheme that enables wallets to send requests to servers via a static QR code and obtain invoices, and a withdrawal request scheme that allows wallets to request servers to pay an invoice they provide. Lightning Network invoices are much longer than on-chain Bitcoin addresses, and payment itself is an interactive process requiring both parties to be online, so it makes sense to interactively coordinate payment information through a network connection.

Three Core Components in Detail:

The authentication protocol works by having the server provide a randomly generated number, which the user's wallet signs using a newly generated key. After receiving the signed nonce, the server saves the associated public key for future login use.
The invoice request function provides users with the information needed to complete a payment in a non-invoice form. This information includes a payment description, the minimum and maximum amounts expected to be paid to the service, and a URL that allows the wallet to request an actual invoice. The wallet presents this information to the user, who sets the final amount and requests an invoice. After sending the invoice request to the server and receiving the invoice, the wallet verifies that the invoice amount matches the user's specified amount and pays the invoice.
The withdrawal request works by sending information to the service, receiving in return a description, a URL for submitting an invoice, a random string (or a deterministic string tied to an account or user), and the minimum and maximum withdrawal amounts. After filling in the appropriate values, the wallet returns the invoice to the server. If the values are valid and within the amount parameter range, the service pays the invoice. The LNURL authentication protocol can be used in conjunction to ensure that only the intended user can successfully complete a withdrawal through the LNURL link.

LNURL has been improved significantly, greatly enhancing the Lightning Network user experience, but it requires the use of a web server. All requests and responses are processed via HTTP, and in addition to the Lightning Network node, other infrastructure is needed to simplify coordination and payment flows. For any online service provider or merchant, this is a very reasonable requirement since they need a web server to provide online services or products anyway. However, for non-technical home users, small vendors, physical stores, and others who do not need a web server, this is a troublesome requirement that also poses security concerns.

BOLT12¶

"BOLT" stands for "Basis of Lightning Technology," a draft technical specification.

BOLT12 is a new Lightning Network invoice specification that includes a new type of invoice: an "offer." An "offer" can be thought of as a "meta" invoice — an invoice on top of an invoice. Compared to BOLT11, it introduces several improvements.

BOLT 12 can achieve some of the core functionality provided by LNURL without requiring a web server. The information required for requesting an invoice is either a node_id or a blinded path for communicating with the node via onion messages (the last few hops of onion routing, pre-computed and encrypted). The onion messaging feature enables nodes to perform end-to-end encrypted communication directly without relying on Lightning Network channels. Like Lightning Network payments, this information can be used for onion-routed messages. After obtaining an offer, the payer sends an invoice request using the information encoded in the offer. The offer creator then returns the actual invoice.

BOLT 12 can also generate unique offers for each user, allowing the recipient to request payment from the offer creator, similar to LNURL's withdrawal request functionality. BOLT 12 invoices commit to the uniqueness of the payer key — in the event of a refund, the payer key can be used to prove who actually paid the invoice. Key uniqueness can also be combined with withdrawal offers to ensure that only the genuine recipient can successfully obtain the invoice paid by the creator, unlike offer copies that anyone can access.

The two uses of offers effectively implement functionality similar to LNURL's invoice and withdrawal request features, without requiring a web server.

BOLT12 Use Cases¶

Subscription Services: A BOLT12 offer can require users to pay an invoice daily, weekly, or monthly (denominated in USD or satoshis). Wallets still need to build this functionality, but the infrastructure will be in place.
Bitcoin Lightning Network ATMs: Offers can send funds to you in the form of credit invoices. This was previously impossible. This can enable a better user experience and drive Lightning Network adoption.
Private Refunds: During refunds, users do not need to create an invoice and send it to the merchant. Instead, users can scan a "refund" offer and receive their money back. This provides better privacy for the recipient and an overall better user experience.

References:

1.https://www.btcstudy.org/2022/07/04/bolt12-lnurl-and-bitcoin-lightning/

2.https://twitter.com/LN_Capital/status/1589321548133203968