A few weeks ago I sat down for the Bitcoin Lightning Network bootcamp at Zone01 Kisumu with a vague idea that Lightning was "the fast version of Bitcoin." That's about as accurate as saying a smartphone is "the fast version of a brick." It's not wrong, but it skips over the part that actually matters: how it works underneath.
This article is a walkthrough of what clicked for me during the first stretch of the bootcamp, mostly around channels and payments. I'm writing it the way I wish someone had explained it to me on day one, with the confusion left in rather than smoothed over.
The problem Lightning is solving
Before touching any Lightning concepts, the bootcamp made us sit with the actual problem. Every transaction on the Bitcoin blockchain has to be broadcast, verified by miners, and included in a block. That's the whole point of Bitcoin's security model, but it means transactions are slow and, depending on network congestion, expensive. Paying for a coffee with an on-chain transaction is technically possible but practically absurd.
Lightning's pitch is: what if two people who transact with each other often didn't have to touch the blockchain every single time? What if they could settle up on-chain only occasionally, while doing the actual back-and-forth payments off-chain, instantly, for nearly nothing?
That's the entire idea. Everything else is just the engineering required to make that idea trustworthy.
Channels: the unit everything is built on
The first real concept is the payment channel. Two parties open a channel by committing funds into a special on-chain transaction, a 2-of-2 multisig output. Both parties have to sign off on anything that happens with that money from this point forward.
Once the channel is open, the two parties can send funds back and forth between each other by exchanging signed updates that represent the current balance split. None of these updates touch the blockchain. They're just signed messages held by both parties, each one superseding the last.
When either party wants to stop, they broadcast the latest balance state to the chain, and the channel closes with funds distributed according to that final state.
What took me a while to get is that the channel doesn't track "transactions" the way I think of them. It tracks a running balance. If I open a channel with 100,000 sats and send my counterparty 5,000 sats, the new state isn't "a transfer happened," it's "the balance is now 95,000 / 5,000." Every payment is really just both parties agreeing to a new split and signing it.
What happens if someone cheats
This is where the bootcamp slowed down and made sure we actually understood it, because it's the part that makes Lightning trustworthy without a central authority.
Each balance update invalidates the previous one. But what stops someone from broadcasting an old state where they had more funds, the one before they sent money out?
The answer is a punishment mechanism. Every time the channel state updates, both parties generate a new commitment transaction, and as part of agreeing to the new state, each party gives the other a revocation secret for the old state. If someone tries to broadcast an outdated commitment transaction, the other party can use that revocation secret to claim the entire channel balance as a penalty.
So broadcasting an old, more favorable state isn't a sneaky shortcut. It's a way to lose everything. The incentive structure does the enforcement, not a referee.
I found this genuinely elegant once it landed. The system doesn't prevent cheating by making it impossible. It prevents cheating by making it economically suicidal.
Routing payments through people you've never met
Channels alone would only let you pay people you've directly opened a channel with, which isn't useful at scale. The next piece is routing payments across a network of channels you're not directly part of.
Say I have a channel with Alvin, and Alvin has a channel with Ronnie. I can pay Ronnie without ever opening a channel with him directly, by routing the payment through Alvin.
The mechanism that makes this safe is Hashed Timelock Contracts, or HTLCs. Ronnie generates a secret, hashes it, and gives the hash to me (via an invoice). I forward a conditional payment to Alvin: "you get this amount if you produce the preimage of this hash, and you have until this block height to do it." Alvin forwards the same conditional payment to Ronnie. Ronnie, who knows the secret, reveals it to Alvin to claim the payment. Alvin now has the secret and reveals it to me to claim his payment.
The result: the payment moves across the route atomically. Either the whole chain of HTLCs resolves and everyone gets paid, or it times out and everyone reverts. Nobody in the middle can walk away with funds without forwarding them, because the only way to claim the incoming HTLC is to produce a preimage they can only get by paying out the outgoing HTLC.
The timelocks decrease as you go further from the payer, which I initially found unintuitive until I realized why: it gives nodes earlier in the route enough time to claim or fail their HTLC after observing what happens downstream.
Setting up nodes and actually sending a payment
The bootcamp had us spin up LND nodes connected to a Bitcoin Core regtest network, open channels between our nodes, and send payments across them. Doing this hands-on is where a lot of the theory actually solidified.
A few things stood out in practice:
Opening a channel is itself an on-chain transaction, so it needs to be confirmed before the channel is usable. On regtest this is trivial since you can mine blocks on demand, but it's a good reminder that Lightning doesn't eliminate on-chain activity, it just minimizes it.
Creating an invoice on the receiving node generates that hash I mentioned earlier, encoded along with the amount and other metadata into a string you'd recognize as a Lightning invoice (the ones starting with lnbc). Paying that invoice from another node is what kicks off the HTLC chain.
Watching lncli output during a multi-hop payment, and seeing the HTLCs appear and resolve across the route in real time, made the routing concept click in a way that diagrams hadn't. There's something about watching the actual state changes happen on nodes you set up yourself that diagrams can't replicate.
What I'm still working through
Channel balance and liquidity management is the next thing on my list. A channel can only route payments in a direction it has capacity for, which means the network's ability to route payments depends heavily on how liquidity is distributed across channels. Rebalancing, fee policies for routing nodes, and how nodes decide on routes (especially with private channels and onion routing for privacy) are all things I've only scratched the surface of.
I'm also curious about how this connects to the broader infrastructure work I've been doing, particularly around building tools that interact with these nodes programmatically rather than through lncli. That feels like a natural next step.
Closing thought
What surprised me most about this first stretch wasn't any single technical detail, it was how much the whole system relies on aligning incentives rather than adding more rules. Channels, revocation secrets, HTLCs, all of it boils down to making honest behavior the only behavior that makes economic sense.
That's a different kind of engineering than I'm used to from typical software work, where you're usually trying to prevent bad states through validation and access control. Here, the bad states are allowed to exist, they're just made unprofitable. I'm looking forward to digging into the next layer of this.
