How Lightning Scales Bitcoin

The Lightning Network can scale bitcoin to tens of millions of daily users, and can allow them to send transactions in fractions of a second, instead of waiting 10+ minutes for ledger confirmation.

The Speed Improvements

Payments don't have to be written to the blockchain

In The Lightning Proposal, we saw Bitcoin moving across the network like this:

Critically, none of these movements of BTC are immediately written to the Bitcoin ledger ("the blockchain"). The Bitcoin ledger is only used to record two events:

1. The opening of a payment channel between two nodes.
2. The closure of a payment channel between two nodes.

And: When sending a payment, you never have to wait for a channel to open, because the network is a connected web of already "open" channels!

A payment can move across the network very, very quickly: As fast as two computers can talk to each other, which is mostly limited by the speed of light.

So, if one lightning node is in New York, and another is in Chicago, a payment might take around 25 milliseconds to move between them.

If one lightning node is in New York, and another is in London, a payment might take around 70 milliseconds to move between them.

In reality, there might be other delays, but, generally speaking, a Lightning payment, even to the other side of the world, under good network conditions, should completely settle within one (1) second.

Lightning payments can be extremely fast because nothing must be written to the blockchain at the time of payment.

The Security Guarantees

But if it's not written to the ledger, how is it secure?

Good question. As we've seen, we only need to write to the blockchain twice:

1. The opening of a payment channel between two nodes.
2. The closure of a payment channel between two nodes.

But there is an important detail to #2, the channel closure: Any node, at any time, can close a payment channel and have the final balances written to the ledger.

Do you see why this is critical? If anything goes wrong, if any node in the network gets nervous about any BTC balances, that node can can "cash out" and the current balances on the channel will be written to the ledger.

So the Lightning network works because, although the movement of BTC between nodes is just private data, only recorded on the hard drives of each node, at any time, these balances can be irreversibly written to the Bitcoin ledger.

How does this work again?

Can you just send anyone a Lightning Payment?

A payment can go from any node, to any other node, as long as there is a route in the network somehow connecting the two nodes.

Some nodes might be directly connected to each other. But most times, your node will have to "route" through intermediary nodes in order to find a path to the final destination.

I'm confused. Show me a map.

A map of the Lightning Network, April 2024. Created with a modified version of this script.

In the above map, the dots are the nodes, and the tiny lines between the dots are the open channels between those nodes.

As of this writing, there are about 15,000 (fifteen thousand) active public nodes on the network, but this number is constantly changing.

Let's close up on just this one part of the network, shown in the blue box....

Here, now we can see the black dots. Each black dot is a public node. The lines are the public channels, connecting the nodes:

The network is so well connected, in fact, that to send payments to almost any node, you might only need ONE connection to ONE existing well-connected node. This is one of the uses of big routing nodes like The Megalith Node.

note

You can skip the info below if you want.

This is awesome. How do I actually learn absolutely everything about the Lightning Network, entirely from scratch?

Good question. This guide you are reading right now is an opinionated, practical guide, and we'll be glossing over many of the most complicated details.

This is on purpose -- most of the existing documentation tends to intermix a lot of really complicated stuff with more simple stuff. I think you should learn the simple stuff first, so that's why I wrote this guide.

But if you really want to learn everything there is to know, here is how to do it:

---

Read these two books

"Mastering Bitcoin: Programming the Open Blockchain (3rd Edition)" (amazon, github)

"Mastering the Lightning Network: A Second Layer Blockchain Protocol for Instant Bitcoin Payments" (amazon, github)

Just those two books together are about 1500 pages of reading. Give yourself at least a week or two, this is complicated stuff.

---

A Guide to the BOLTS

To really get down-and-dirty with the Lightning Network, you need to read the BOLTS: "Basis of Lightning Technology". And probably read them five or six times, if you want to have any hope of fitting them in your brain permanently.

Note -- you can skim the BOLTS any time, just to a get a feel, but before you go through them "for real" and try to understand everything, I strongly recommend that you read the books linked above, and quite carefully.

The BOLTS are the "specification" for the Lightning Network. They were written by individuals considerably smarter than myself.

info

The original Bitcoin project does not have a formal specification, instead it has something called a "reference implementation" -- the software Bitcoin Core, which you can find at this Git repository. After his original short paper, Satoshi just went ahead and wrote software to run Bitcoin, and things progressed from there. In contrast, The Lighting Network has been put together in a somewhat more organized way, with a short list of documents (the BOLTs), which describe the intended behavior of the network. The Lightning software implementations -- LND, CLN, Eclair, LDK -- the software you actually use to run a node, are all built using the BOLTs as a "guide" or "blueprint". The BOLTS are the scripture, and the lightning software implementations are the "facts on the ground", or "deployed systems".

[BOLT #1] This is the "wire protocol", meaning how the actual bytes (in hexadecimal) are organized into messages that go over the network. This is for super-nerds, and you might be better off not trying to understand this fully anytime soon. I am personally not smart enough to really understand all of this.

[BOLT #2] This is the "peer protocol", which is the complicated and formal sequence of messages which peers send to each other. This stuff is important and, once you start running a node, messages like open_channel and channel_read and update_add_htlc will make sense to you.

[BOLT #3] Also important, this shows you the actual Bitcoin script -- the actual computer language -- that is written to the Bitcoin blockchain, in the course of opening and closing Lightning channels. I have read this several times and would definitely fail a written test on its contents.

[BOLT #4] More details about "Onion Routing", the hard-to-understand way that nodes talk to each other, and how that communication is secured. This one helpfully combines things that you probably should understand, like multi-path payments, with things that you almost certainly will never be able to understand, like B(i) = HMAC256("blinded_node_id", ss(i)) * N(i).

[BOLT #5] "On-chain Transaction Handling". Read this one five times, then take a week off and read it another five times. This one is super-important because it deals in great detail with the nastiest, most difficult part of the Lightning Network for node running practitioners: closing channels.

[BOLT #7] "P2P Node and Channel Discovery". My personal favorite because I actually think I understand most of this. You see, nodes on the Lightning Network are always chattering with each other -- it's called "gossip", and it is how information about public channels travels around the network.

[BOLT #8] "Encrypted and Authenticated Transport". Here's a little sample of this gem:

# Act Three
    input: 0x00b9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c38228dc68b1c466263b47fdf31e560e139ba
    # decryptWithAD(0x908b166535c01a935cf1e130a5fe895ab4e6f3ef8855d87e9b7581c4ab663ddc, 0x000000000100000000000000, 0x90578e247e98674e661013da3c5c1ca6a8c8f48c90b485c0dfa1494e23d56d72, 0xb9e3a702e93e3a9948c2ed6e5fd7590a6e1c3a0344cfc9d5b57357049aa22355361aa02e55a8fc28fef5bd6d71ad0c3822)
    # rs=0x034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
    # h=0x5dcb5ea9b4ccc755e0e3456af3990641276e1d5dc9afd82f974d90a47c918660
    # ss=0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766
    # HKDF(0xe89d31033a1b6bf68c07d22e08ea4d7884646c4b60a9528598ccb4ee2c8f56ba,0xb36b6d195982c5be874d6d542dc268234379e1ae4ff1709402135b7de5cf0766)
    # ck,temp_k3=0x919219dbb2920afa8db80f9a51787a840bcf111ed8d588caf9ab4be716e42b01,0x981a46c820fb7a241bc8184ba4bb1f01bcdfafb00dde80098cb8c38db9141520

Fun, right? This one will be smooth sailing for anyone who has a PHD in Cryptography. That's not me, and if that's not you, leave this one to last or maybe just skip it.

[BOLT #9] "Feature flags". Actually very useful and not impossible to understand.

[BOLT #10]. Networking details for nerds. Not necessary to understand.

[BOLT #11] The current (as of 2024) invoicing format. Important reading.