Bitcoin transactions cannot become final in a few milliseconds. They compete for limited block space, and a new block is mined only about every ten minutes on average. So how can a Lightning payment reach a shop on the other side of the world almost instantly, for a very small fee?

The answer is not a faster blockchain. Lightning payments are not written to the Bitcoin blockchain at all, at least the large majority of them.

Instead, Lightning users lock bitcoin into so-called payment channels and exchange signed updates that change who can claim those coins. These channels form a network, allowing a payment to travel through several participants even when sender and recipient do not have a direct connection. 

Many have used the Lightning network already, but few understand how it actually works. Let’s take it apart one piece at a time.

Why do we need Lightning?

Every regular Bitcoin transaction must be distributed across the entire network, verified by nodes, included in a block, and stored in the blockchain forever. This makes Bitcoin independently verifiable: anyone can run a node and check the complete history without asking a bank or payment processor for permission.

That property comes with a deliberate constraint. Block space is limited, which means not every single person in the world can buy their morning coffee with a regular Bitcoin transaction. There is simply not enough room. Increasing the block size without limits would raise the bandwidth, computing, and storage requirements for running a node, making independent verification more and more difficult.

Lightning therefore takes a different approach. Bitcoin transactions remain as the settlement layer, while repeated payments happen on a second layer. Rather than asking the entire Bitcoin network to record every coffee purchase, two participants can settle many payments between themselves and publish only the result when necessary.

An important aspect to keep in mind is: Lightning is Bitcoin. It is still deeply tied together with the Bitcoin network and not “a new coin”. Lightning payments are Bitcoin payments, they just use the limited block space available more efficiently and less frequently.

A payment channel starts on Bitcoin

Imagine Alice wants to use 0.001 BTC or 100,000 satoshis for Lightning payments. She opens a channel with Bob by creating a Bitcoin transaction that locks those coins into a wallet controlled by both channel participants. You can think of it as a special 2-of-2 multisig wallet, where both Alice and Bob hold a key and can only spend funds together. 

As we will find out later, there are some important properties this multi-sig wallet needs to fulfill in order for the payment channel to function securely and without trust. But for now, these details are not important.

The funding transaction is recorded on the Bitcoin blockchain. Once it has enough confirmations, the channel can be used for payments.

At the start, the channel might look like this, with all of the balance on Alice’s side, since she sent the opening transaction:

  • Alice: 100,000 sats
  • Bob: 0 sats
  • Total capacity: 100,000 sats

Remember the bitcoin have not left the blockchain. They are just sitting in a different wallet now. What changes during the life of the channel is the valid agreement about how that money can be spent. Let’s explore an example…

Payments are agreements

Imagine a rental contract for an apartment where you have to pay a security deposit of 1000 USD to the owner. When the contract is cancelled, the landlord is obligated to pay back those 1000 USD. But let’s say you want to pay the landlord for a piece of their furniture you damaged. You could just send them a regular bank transaction or hand them cash. However, both of you could instead just update the rental contract to a lower security deposit, e.g. to 900 USD. That way, you effectively paid 100 USD to the owner, without moving any money, just by updating a contract. 

This is (more or less) exactly how a Lightning channel operates. The 1000 USD in this example would be the channel capacity, and you and the landlord could “send” each other money by updating the contract as often as you like. And once the contract ends, you just settle whatever amount is currently set as the security deposit.

The contract in Bitcoin

In Bitcoin, we’re not talking about rental contracts, of course, but transactions. The two concepts are not far apart though, as signing a Bitcoin transaction is conceptually almost the same as signing a contract. 

Let’s get back to our payment channel: Suppose Alice pays Bob 20,000 sats. They do not create and broadcast a regular Bitcoin transaction. Instead, their Lightning nodes construct and sign a new pair of settlement transactions reflecting the updated balance:

  • Alice: 80,000 sats
  • Bob: 20,000 sats

These are called commitment transactions. Each participant holds a valid transaction that they could publish to close the channel and pay out the latest agreed balance at any time. The two versions differ in their details because each is designed to be published by one particular side, but both represent the same channel state.

If Bob later pays 5,000 sats back to Alice, the nodes create another state and another set of unpublished transactions:

  • Alice: 85,000 sats
  • Bob: 15,000 sats

Again, nothing has been broadcast to the Bitcoin network. Alice and Bob have simply replaced their previous settlement agreement with a newer one. They can repeat this process many times without waiting for a block or paying transaction fees. Just like with the updated security deposit in the rental contract.

This is the first important insight about Lightning: an off-chain balance in a Lightning channel is not an entry in a global ledger like regular transactions. It is the latest set of Bitcoin transactions that the channel participants have signed.

Stealing channel balance

Now, you might raise the question why Alice, for example, would not simply broadcast an old settlement agreement to the Bitcoin network. Signed Bitcoin transactions stay valid afterall, and in doing so, she could effectively revert the payments she made to Bob, or in other words, steal the coins. 

In our rental contract example from before, the judicial system, i.e. a judge in court, would be able to settle a dispute between landlord and tenant, honoring the most recent signed contract between the two. In Bitcoin, that process is more complicated. We need a purely technical mechanism, since there is no trusted third party we can rely on.

Whenever a channel moves to a new state, both parties exchange information that revokes the previous one. This is done cryptographically by revealing a certain key, which the other party can use in case you try to cheat. If Alice attempts to broadcast an already revoked commitment transaction, i.e. she tries to cheat, her own payout is delayed. During this delay, Bob can use the revocation information to prove that Alice published an old state and claim all of the funds she tried to take.

The exact scripts used in these transactions are more complex, but the incentive is simple: trying to settle an outdated balance can cost the dishonest party their entire channel funds. Not only that, because they also lose economic trust within the network, disincentivising others to open new channels with them.

This penalty mechanism also explains why a Lightning node cannot ignore the blockchain forever. Bob must detect an outdated channel close and react within the dispute window. The node does not need to be online every single second, but it must check often enough, or delegate this monitoring to someone else – which is what you would call a watchtower. This is one of the major security compromises of Lightning: you need to keep an eye on your money.

Channels form a network

You might have guessed it: The concept of a single payment channel, enabling an arbitrary number of payments between two participants, can now be extended to a network of interconnected payment channels, enabling an arbitrary number of payments between many more participants.

A channel between Alice and Bob is useful, but opening a separate channel with every person or shop would defeat much of the purpose. Instead, Bob may have another channel opened to Carol, who in turn has a channel open to David.

This now enables Alice to create a payment to David, routing the payment across different channels:

Even though Alice has no direct channel with David, we can update all three channels such that value moves from Alice to David:

  1. Alice sends 1,000 sats to Bob.
  2. Bob sends 1,000 sats to Carol.
  3. Carol sends 1,000 sats to David.
  4. David effectively received 1,000 sats from Alice.

Bob and Carol forward the payment using bitcoin they already have available on the correct side of their own channels. They may charge a small routing fee for providing this service, i.e. liquidity and keeping their nodes online. This is why Lightning payments still come with a small transaction fee. 

Unfortunately, that’s not the end of the story, because we just created a new problem: Alice should not pay Bob unless she can be sure David gets paid. Bob should not pay Carol unless Alice’s incoming payment is guaranteed. And Carol should not be able to take Bob’s money without completing the payment to David.

Lightning solves this with conditional payments.

When David creates a typical Lightning invoice, his wallet generates a random secret. The secret itself is called a preimage – a fancy cryptography term for “what existed at the beginning”. The wallet then puts a fingerprint of this preimage, i.e. a hash value, in the Lightning invoice.

Alice uses that payment hash to set up a chain of so-called Hashed Timelock Contracts, usually abbreviated as HTLCs. Each contract says, in simplified terms:

You can claim this payment if you reveal the secret matching this hash before the deadline. Otherwise, the sender gets the money back.

Alice offers such a conditional payment to Bob. Bob offers a corresponding one to Carol, and Carol offers one to David. The deadlines become shorter toward the recipient such that every forwarding node has time to recover its incoming payment if a later hop must be resolved on-chain.

David knows the secret, so he can reveal it and claim the final payment. Once Carol learns the secret, she can claim the money from Bob. Bob can then finally claim from Alice. The same proof unlocks the payment backwards along the entire route.

If the route breaks or David never reveals the secret, the HTLC expires and the pending changes are cancelled or refunded. This makes the payment atomic: it either completes across the entire route, or it fails without leaving anyone hanging, having paid the next while receiving nothing in return.

In normal operation, all of this happens through messages between Lightning nodes. The HTLC transactions matter because every participant could enforce the outcome on Bitcoin if cooperation breaks down. In other words: All of these fancy contracts, with cryptography ensuring nobody can cheat, are once again just signed Bitcoin transactions. If something goes wrong, the transaction can be published on the Bitcoin blockchain, and the coins return to where they belong.

How a channel closes

Just like any rental contract, a Lightning channel will not remain open forever, and there are two main ways to close it.

  • In a cooperative close, both participants agree on the final balance and sign a closing transaction. This is usually the cheaper and simpler outcome. Once that transaction confirms, each participant controls their share directly on-chain again. Staying in our analogy, the tenant and landlord have simply agreed on the final deposit amount to be paid out.
  • In a unilateral close, one participant publishes their latest commitment transaction without the other participant’s cooperation. This is sometimes called a force close. It is an essential safety feature: neither side can hold the other’s bitcoin hostage by going offline or refusing to sign.

A unilateral close is slower and may be more expensive. Timelocks must expire, and unresolved HTLCs can require additional on-chain transactions. But as long as the user has the latest valid channel state and monitors the blockchain when necessary, the protocol provides a unilateral exit enforced on the Bitcoin blockchain.

This is the foundation of Lightning’s security model. Participants cooperate for speed, but they do not have to trust each other with custody. The Bitcoin network acts as the final judge when they disagree, just like in the rental contract example.

That’s it! We have broken down the key parts of a payment in the Lightning network. Of course, there would be plenty of opportunities to dive deeper from here: How does a node even find a route across the network? Are there different penalty mechanisms and how do they compare? How can liquidity constraints be circumvented? But for now, let’s leave it at the core components.

Where a hardware wallet fits

A hardware wallet and a Lightning wallet solve entirely different problems.

The BitBox is designed to keep your private keys safe for long-term holdings and transactions have to be confirmed and verified manually on its secure display. This is great for security, but impractical for Lightning: every time a payment is sent or received, new channel states need to be signed in interaction with other Lightning nodes. Unless you camp at your hardware wallet 24 hours a day, ready to confirm an incoming payment. 

For many users, the practical setup is therefore similar to a savings account and a physical wallet: keep larger amounts in cold storage on a hardware wallet, and move only a smaller spending balance to a non-custodial Lightning wallet. This limits the amount exposed if the phone, computer, or Lightning wallet is compromised while preserving the convenience of instant payments.

Self-custody still matters on Lightning. Before choosing a wallet, check whether you control the keys yourself, how recovery works, who manages the channels, and what happens if the wallet provider disappears. “Lightning wallet” describes a payment technology, not one universal security model.

We are still actively working on integrating a Lightning wallet into the BitBoxApp, enabling a seamless user experience between these two wallet philosophies. The hardware wallet can still play a role, however, by deriving the private keys for the Lightning wallet from its own backup, to avoid having to manage a new backup for the Lightning wallet.

Conclusion

The Lightning Network is not a separate part of bitcoin and not a shortcut around Bitcoin’s rules. It is a network of payment channels backed by real Bitcoin transactions.

Channel participants update signed transactions instead of broadcasting every payment. Revocation mechanisms discourage either side from cheating on each other. Complex Bitcoin scripts link several channels so a routed payment either completes from end to end or fails safely.

That is how Lightning can feel instant without relying on a central payment processor. Its speed comes from moving routine activity off-chain; its security comes from keeping a path back to Bitcoin. The result is well suited to everyday payments, provided users understand the tradeoffs around liquidity, availability, backups, and hot-wallet risk.

For long-term savings, cold storage will generally remain the better tool. For small, frequent payments, Lightning provides a compelling complement – not a replacement – to the Bitcoin main layer.

Don’t own a BitBox yet?

Keeping your crypto secure doesn't have to be hard. The BitBox hardware wallets store the private keys for your cryptocurrencies offline. So you can manage your coins safely.

Both the BitBox02 Nova and the BitBox02 also come in a Bitcoin-only edition, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing bitcoin.

Buy the BitBox02 Nova or grab a BitBox02 in our shop!

Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease — along with its software companion, the BitBoxApp!