A Payment Channel lets participants change the allocation of jointly locked bitcoins through digitally signed agreements. A signature confirms agreement to the new allocation; each update need not enter the blockchain, the public record of Bitcoin transactions. Participants still have a way to close the channel and settle on the blockchain. This entry describes a conventional two-party Lightning channel with revocation: an earlier agreement can be withdrawn, and using it later can trigger a penalty. Other channel designs may follow different rules.
Imagine two parties continually updating their claims to a jointly locked amount. Each payment does not need its own Bitcoin transaction in a block. Instead, the parties exchange signatures for a new state. This is more than a spreadsheet they must trust: they hold transactions that can enforce settlement under the agreed conditions. [1] [2]
A funding transaction puts bitcoins into the channel. Its output is an amount with rules about who may spend it; confirmation means the transaction has been included in a block. In a conventional Lightning channel, this output requires both parties’ signatures: 2-of-2. Before funding is broadcast, the participants must have a valid way to close unilaterally. Normally they wait for funding confirmations. Under certain conditions, zero-conf allows channel use without waiting for confirmation. The receiver then relies more on the party funding the channel: the transaction is still unconfirmed and could be replaced by a conflicting transaction. [2] [3]
A commitment transaction is a transaction signed in advance to settle the currently agreed allocation. Here, a node is the software managing the channel and its updates. Each party has its own version of the commitment transaction. During an update, nodes coordinate signatures and revocation secrets through commitment_signed and revoke_and_ack. A newer agreement does not invalidate an old signed transaction under Bitcoin consensus. Protection against publishing a revoked state must therefore be built into the output conditions. [2] [3]
In a conventional revocation channel, the party publishing its commitment waits to spend its own funds for to_self_delay. The delay is counted in blocks from confirmation of the commitment transaction. If it published a revoked state, the other party can use the revocation key to make a remedial spend of the relevant outputs. It must act in time and get the transaction confirmed. A Watchtower is a service that monitors the chain and can use data prepared in advance to respond to publication of a revoked state. That service still cannot guarantee success or replace a backup. [3] [4]
Sat is short for satoshi, the smallest unit of bitcoin on the chain. Capacity is the channel’s total amount, not each participant’s balance. Consider a 100000 sat channel: Alice holds 70000 sat and Bob 30000 sat. If Alice pays Bob 10000 sat, their new balances are 60000 sat and 40000 sat. We ignore fees and reserves to keep the example clear. Capacity has not changed, but Alice can now send less and receive more. Reserves and pending payments also affect the real limits. [6]
Lightning finds routes through connected channels. An HTLC is a conditional payment: claiming the funds requires revealing a secret value, the preimage, whose hash or digital fingerprint matches the value known in advance. Time conditions also allow settlement when a payment does not complete. Intermediaries need liquidity, meaning funds available to send in the required direction, and can charge fees. You do not need a direct channel with every merchant, but connectivity alone does not guarantee a usable route for any amount. [2] [4]
In a cooperative close, participants agree on a closing transaction, the distribution of funds and the fee. Both sign it and broadcast it on-chain. This is usually simpler than unilateral settlement, but it is not automatically free or immediate. The transaction still needs confirmation and a fee suited to network conditions. [2] [4]
A unilateral closure, or force close, publishes your current commitment without fresh consent from your peer. Funds may not be spendable immediately: delays and any HTLC resolution still apply. Further transactions and fees may be needed. There is an emergency exit, but its timing and cost depend on the channel state and blockchain conditions. [3] [4]
A Seed Phrase is a set of backup words from which a wallet can restore its keys. On its own it does not restore the latest state of an open channel, so follow the recovery procedure for your particular wallet. For example, LND, a program for running a Lightning node, uses those words together with a Static Channel Backup (SCB). This static backup stores the details needed to contact peers and ask them to close channels; it does not restore channels for continued payments. Recovery this way also depends on peers responding. The channel.db file, in contrast, holds the channel database, and an old copy can contain dangerously outdated state. Never enter your real backup words on an unfamiliar website to “repair” a channel. [5]
Find out who holds the keys, who monitors channels and how you recover access after losing a device. Custodial means the service provider holds the keys. A Lightning balance at a custodial service may not represent your own channel. With self-custody, you take responsibility for backups, availability and responding to problems. Channels save blockchain entries; they do not remove every operational duty or settlement cost. [4] [5]
For the clearest picture, read this entry together with Lightning Network, HTLC, Lightning liquidity, Lightning Watchtower. The reverse links also lead from Confirmation, Double-spend, Timelock, HTLC.