This is a study note of Mastering Lightning Network.


The Lightning Network uses a game theoretical fairness protocol that is a way to achieve fair outcomes between participants, who do not need to trust each other, without the need for a cental authority. It is a system of incentives and disincentives defined in a set of interaction rules.

The fairness protocol requires security primitives as building blocks. The primitives include strict time ordering/sequencing, hash functions to fingerprint data, digital signature for authentication, nonrepudiation and proof of ownership of a secrete, and encryption/decryption for privacy.

In February 2015, Joseph Poon and Thaddeus Dryja proposed the lightning network (LN) as a solution for scalable off-chain payment system. In LN, transaction take place off-chain, only the initial loading and final settlement transactions needing to be validated and stored by Bitcoin nodes.

LN is a second layer porotocol on top of Bitcoin and other blockchains to enable fast, secure, private, trustless, and permissionless payments. It has following features:

  • Users can route payments to each other for low cost and in real time.
  • There is no need to wait for block confirmation for payments.
  • A payment is completed and finalized in a few seconds.
  • LN trasactions are not visible to public.
  • LN transactions don’t need to be stored permanently.
  • LN uses onion routing that has good pravicy protection.
  • LN uses the real bitcoin.

2 Getting Started

A LN wallet may include:

  • A keystore that holds secrets, such as private keys. An internal keystore is called noncustodia or self-custody. An external keystore is custodial one.
  • An LN node.
  • A light Bitcoin node.
  • A database “map” of nodes and channels that are announced on the LN.
  • A channel manager that can open and close LN channels.
  • A close-up system that can find a path of connected channels from payment source to payment destination.

A LN wallet or node is a channel peer to another LN wallet. Once “opened”, a channel can be used to do many transactions between a pair of peers. Furthermore, a peer can forward payments via other channels further into the LN. A peer can route a payment to any wallet as long as the wallet can find a viable path made by channel hopping. Not all channel peers are good peers for routing payments. Well-connected peers will be able to route payments over shorter paths to the destination, increasing the chance of success. Channel peers with ample funds will be able to route larger payments.

When open a channel, the wallet creates a funding transaction that secure the fund from Bitcoin bloackchain. To accept LN payment, a LN node needs BTCPay Server that could be a full BTC node or a light BTC node.

3 Payment Channels

At this time, channels are funded only by one of the two channel partners: when you choose to “open” a channel, you deposit funds into the 2-of-2 multisig address with a transaction.

Each node generates a root private key when first initialized. The private key is kept private at all times (never shared) and securely stored in the node’s wallet. From that private key, the node derives a public key that is the node identifier and shared with the network. The full node id has a format of NodeID@Address:Port.

3.1 Channel Establishment

The channel establishment involves three parts.

  • First, the two peers communicate their capabilities and expectations, with Alice initiating a request through open_channel and Bob accepting the channel request through accept_channel. The two peers set up parameters and exchange public keys for the 2-of-2 multisig address.
  • Second, Alice constructs the funding and refund (commitment) transactions and sends funding_created to Bob. Bob responds by sending back the necessary signatures with funding_signed – it is Bob’s signature for the refund transaction that Alice to claim her bitcoin back from the multisig. Alice will now broadcast the funding transaction (on-chain) to establish and anchor the payment channel. The transaction will need to be confirmed on the Bitcoin blockchain.
    • Alice sends some bitcoin to funding transaction that has a 2-of-2 multisig address script 2 <Alice_funding_pubkey> <Bob_funding_pubkey> 2 CHECKMULTISIG in output. The script is encoded as a Pay-to_Witness-Script-Hash (P2WSH) Bitcon address. She holds the signed transaction by not broadcasting it. It has a lock time for each peer.
    • Alice create the refund transaction, a commitment transaction, that spends the 2-of-2 multisig in the funding transaction back to Alice’s wallet. In funding_created message, she sends her signature of multisign and funding transaction ID.
    • In funding_signed message, Bob sends his signatue id for the refund transaction based on his funding_pubkey of the multisign.
  • Alice sends the funding transact to Bitcoin. Once the transaction has sufficient confirmations (as defined by the minimum_depth field in the accept_channel message, It may takes six confirmations – about an hour?), Alice and Bob exchange funding_locked messages, and the channel enters normal operating mode.

3.2 Sending Payments Across the Channel

The first commitment transaction shown in Multiple commitment transactions is the refund transaction that Alice constructed before funding the channel. After that, all Alice and Bob have to do is create and sign a transaction that spends the 2-of-2 multisig to two outputs paying Alice and Bob their corresponding balances. We call this updated transaction a commitment transaction. Alice and Bob operate the payment channel by advancing the channel state through a series of commitments. Each commitment updates the balances to reflect payments that have flowed across the channel. Both Alice and Bob can initiate a new commitment to update the channel.

Each signed and valid commitment transaction can be used by either channel partner at any time to close the channel by broadcasting it to the Bitcoin network. Since they both have the most recent commitment transaction and can use it at any time, they can also just hold it and not broadcast it. It’s their guarantee of a fair exit from the channel.

There is a built-in penalty mechanism that ensures it is not in the best interest of a would-be cheater to transmit an old commitment transaction. It has three elements:

  1. Asymmetric commitment transactions: Alice’s commitment transactions are slightly different from those held by Bob. Each peers has different outputs: to_local with self address and to_remote with remote address.
  2. Delayed spending: The payment to the party holding the commitment transaction is delayed (timelocked), whereas the payment to the other party can be claimed immediately. The delay is negotiated by Alice and Bob, during the initial channel construction message flow.
  3. Revocation keys: Used to unlock a penalty option for old commitments. The way this works is that the to_local output is not only timelocked, but it also has two spending conditions in the script: it can be spent by local after the timelock delay or it can be spent by remote immediately with a revocation key for this commitment.

3.3 Revocable Transaction

The to_local output has the following structure:


The two branches allow the remote to spend immediately with the signature of remote_revocation_pubkey but the local node has to wait a delayed number of blocks to spend it. A critical requirement to the security of this script is that the remote party cannot unilaterally sign with the remote_revocation_pubkey.

In channel creation, Alice and Bob exchange their revocation_base_point (rbp), let’s call it rbp_A for Alice’s revocation base point and rbp_B for Bob’s revocation base point. The two revocation base points are used for the lifetime of the channel to derive other keys. Each party keeps the corresponding prividate key rbps_A and rbps_B confidential. rbps stands for revocation_base_point_secret.

Each new channel state will be based off a new per_commitment_point (pcp). Because there are many of commitment transaction, we use an index starting from 0 to number each transaction. For the first commitment transaction, we us have two pcps: pcp_0_A for Alice and pcp_0_B for Bob. The corresponding private keys are pcps_0_A and pcps_0_B.

The first commitment transaction CT_0_A created by Alice has three outputs:

  • the to_remote output pays to Bob’s public key via P2WPKH
  • the to_local delayed output to Alice’s public key after some relative delay
  • the to-local immediate output to revocation_pubkey_0_A that ris derived from two public keys: Alice’s per commitement point pcp_0_A and Bob’s revocation base point rbp_B.

The first commitment transaction CT_0_B created by Bob has three outputs:

  • the to_remote output to to Alice’s public key via P2WPKH
  • the to_local delayed output to Bob’s public key after some relative delay
  • the to-local immediate output to revocation_pubkey_0_B that is derived from two public keys: Bob’s per commitement point pcp_0_B and Alice’s revocation base point rbp_A.

The remote_revocation_pubkey in to_local output is derived from the two public keys using the following formulas:

  • remote_revocation_pubkey_0_A: rbp_B * sha256(rbp_B || pcp_0_A) + pcp_0_A * sha256(pcp_0_A || rbp_B).
  • remote_revocation_pubkey_0_B: rbp_A * sha256(rbp_A || pcp_0_B) + pcp_0_B * sha256(pcp_0_B || rbp_A).

Each new commitment transaction n uses a pair of new per_commitment_point that represented by pcp_n_A, pcp_n_B and theire coreesponding private keys pcps_n_A and pcps_n_B. n is the sequential index number for each commitment transaction. Because the remote_revocation_pubkey is derived from public keys, both Alice and Bob can calcuate the two keys remote_revocation_pubkey_n_A and remote_revocation_pubkey_n_B. But none of them can create the corresponding signature because each peer owns one of the two secrets used to create the two remote revocation public keys.

When you want to create a new commitment transaction, you revoke the preivous one by sending the previous per_commitment_secret (pcs) to the remote. The remote can derive the private key revocation_priv for the revocation_pubkey if you broadcast the revoked-commitment with the following operation:

  • For Bob to get remote_revocation_priv_n_A with pcps_n_A: (rbps_B * sha256(rbp_B || pcp_n_A)) + (pcps_n_A * sha256(pcp_n_A || rbp_B)) mod N.
  • For Alice to get remote_revocation_priv_n_B with pcps_n_B: (rbps_A * sha256(rbp_A || pcp_n_B)) + (pcps_n_B * sha256(pcp_n_B || rbp_A)) mod N.

The reason is that revocation_pubkey = rbp * sha256(rbp || pcp) + pcp * sha256(pcp || rbp) = G * ((rbps * sha256(rbp || pcp)) + (pcps * sha256(pcp || rbp))).

3.4 Advance Channel State

To advance the state of the channel, Alice and Bob exchange two messages: commitment_signed and revoke_and_ack messages. The commitment_signed message can be sent by either channel partner when they have an update to the channel state. The other channel partner then may respond with revoke_and_ack to revoke the old commitment and acknowledge the new commitment.

For example, if Alice wants to change state from n to n+1, she create a transaction and sends her signature using commitment_signed. When Bob receives and agrees with the new transaction, he sends a revoke_and_ack messages that includes his private key of the previous per-commitment-point pcps_n_B. Bob also sends commitment_signed with his signaure and Alice sends revoke_and_ack with pcps_n_A. The new chanel state is set. Each party keeps the transaction created and signed by the counterparty.