Layer Two

Pica Pica

The lightning network is a “layer 2” application on top of bitcoin.


While base layer Bitcoin is a slow-moving bedrock that places caution and consensus before all else, the LN is a fast-paced, amorphous network of relationships that are inherently volatile.

The Lightning Network is comprised of a graph of nodes whose edges are called channels. A node can pay another node by sending a transaction through a path of channels, every node is not connected to every other node.

in the beginning…unidirectional

Channels are built off of two concepts:

A unidirectional channel with a set end time (e.g. will close 3 days from now) is pretty easy to model with these ideas in mind.

  1. A 2-of-2 multisig transaction is created (not yet broadcasted) between the 2 parties. A is paying B, so A funds the whole transaction.
  2. Before broadcasting this “funding” transaction though, another transaction is created based on the funding transaction (so it requires both A and B’s sigs). This “refund” transaction is a special case “commitment” transaction which sends all the funds back to A with a timelock of 3 days.

What are the incentives of the first commitment transaction?

After the funding transaction is broadcasted, A and B can trade within the offchain channel by exchanging new commitment transactions. These transactions are not broadcasted to the blockchain, but they are valid transactions which could be broadcasted at any point. Each commitment transaction is a possible closing transaction.

Since this is a unidirectional channel, the transactions are updated where A pays B a little bit more for each transaction. This is done by A receiving less from the multsig when the channel is closed. A signs the transaction and gives it to B as payment, B does not have to sign or broadcast the transaction yet.

A commitment transaction is a transaction that pays each channel partner their channel balance and ensures that the channel partners do not have to trust each other. By signing a commitment transaction, each channel partner “commits” to the current balance and gives the other channel partner the ability to get their funds back whenever they want.

What are the incentives after the first commitment transaction?


Bidirectional channels require more un-broadcasted transactions and timelock layering to make sure incentives stay aligned. If we kept the same protocol from the simpler unidirectional model, A could send a transaction that pays B less as a form of B paying A (bidirectional). But there is nothing stopping B from broadcasting an old commit transaction which A has already signed given B more bitcoin. This isn’t a problem in unidirectional channels where B would need to sign a transaction and broadcast it (A would never get B sig on an old tx).

Bidirectional channels require a disincentive to broadcast old commitment transactions.

The bitcoin script is complex, but this is the basic gist:


The real world script uses more complex RIPEMD160 to minimize bytes in the transaction to minimize fees.

The contract requires some way to fail gracefully in case parties don’t cooperate and share the secret, else funds would be locked up.


This is the beginning of a Revocable Sequence Maturity Contract, or RSMC, to cancel old commitment transactions.

What are the incentives of the bidirection contract?

So how are bidirectional channels created? They are funded the same as unidirectional. But the commitment transactions are more complex. There is now a pair of commitment transactions per payment.

A mechanism is required to not spend old commitment transactions (a.k.a steal). We need new commitment transactions to somehow invalidate the old.

In simple terms, Alice signs Bob’s new commitment transaction only if Bob offers his half of the revocation secret for the previous commitment. Bob only signs Alice’s new commitment transaction if she gives him her half of the revocation secret from the previous commitment.

What are the incentives in the bidirectional channel with revocation secrets?

A channel can be closed cooperatively which doesn’t involve timelocks and each party gets their funds immediately.


Not all nodes in the network are directly connected, but it is still possible to make payments from any node to another, hoping from one node to the next.

(A) -> (B) -> (C)

A is routing a payment to C through B

B will only update its commitment transactions with C if there is no chance the complementary commitment transaction from A will fall through. So the A to B timelock needs to be higher (last longer) than the timelock from B to C. If they were the same timelock, it would be possible for the A -> B transaction to be revoked by A, right as B got the (now worthless to B) secret from C.

The preimage secret (sha256(preimage) == payment_hash) is used to settle (or “unwind”) an in process HTLC. update_fulfill_htlc updates a channel with the value of the HTLC. While there is not a huge incentive for A and B to “clean up” a completed HTLC output in the commitment transactions, there isn’t an incentive not too either.

A decrementing timelock is necessary to protect against race conditions that would leave a users hanging (paid it forward, but never received).

These multi-hop transaction contracts are called Hash Time-Lock Contracs (HTLCs) and are how payments are routed across payment channels as of 2022 (could change with new tech in the future).

Routing Operations


In order to provide liquidity for routing payments and to earn fee income, Lightning node operators need to lock up capital (Bitcoin) inside payment channels.

Opening a channel requires a bitcoin transaction. Closing a channel requires another bitcoin transaction. This encourages long lived channels to avoid the overhead.

  1. Outbound (local)
    • owned by node operator
    • when an operator opens a channel its initially all outbound (the funding transaction is entirely one sided)
    • opening channels only gives you capacity to send, not to receive, balance is all on one side: A(1) -- B(0)
  2. Inbound (remote)
    • not owned by node operator

fee market

Fees are applied only once per channel by the party which is forwarding the fee. Meaning, as you push a payment to your neighbor node, you are able to charge a fee, and as payments are pushed to you, your neighbor charges the fee, even if the channel was created by you.

The fee rate is different than on chain where the cost is MB instead of the value being sent. In the LN, liquidity is valuable so the fee is actually based on the value. If this was 0, one huge transaction could dry up a channel and it would only earn the base fee. It probably wouldn’t cover its opening/closing on chain costs.

The reasoning is: a lot of small payments are sustainable on my channels, no problem, but using up a lot of my liquidity is not sustainable