Lightning Network is a scaling solution to keep most transactions off-chain while leveraging the security of the bitcoin chain as an arbitration layer. There are several concepts to review before jumping into the domain. We will start small by covering lightning primitives, then apply these primitives to describe the Lightning Network.
Payments channels is a construct between two parties that commit funds and pay each other by updating a balance redeemable by either party. Moving funds between each part is near instant. Channels have a total capacity that is established by the on-chain funding transaction. Additionally, each party in the channel has their own balance. For example, a channel between Alice and Bob can have a 1 BTC capacity, but 30% of the bitcoin is owned by Bob. For Alice, this means that her local_balance is 0.7 BTC while the remote_balance (Bob’s balance) is 0.3 BTC.
To create the payment channel construction, a funding transaction is created on-chain. Any updates to the channel involves updating the commitment transaction.
Hash Time-Locked Contracts (HTLCs) allow transactions to be sent between parties who do not have a direct channels by routing it through multiple hops, so anyone connected to the Lightning Network is part of a single, interconnected global financial system.
Payment channels are the main workhorse of the Lightning Network. They allow multiple transactions to be aggregated into just a few on-chain transactions. In the vast majority of cases, someone only needs to broadcast the first and last transaction in the channel.
- The Funding Transaction creates the channel. During this stage, funds are sent into a multisig address controlled by both Alice and Bob, the counterparties to the channel. This address can be funded as a single-payer channel or by both Alice and Bob.
- The Closing Transaction closes the channel. When broadcast, the multisig address spends the funds back to Alice and Bob according to their agreed-upon channel amount.
channel updates
- In between the opening and closing transactions broadcast to the blockchain, Alice and Bob can create a near infinite number of intermediate closing transactions that gives different amounts to the two parties.
- For example, if the initial state of the channel credits both Alice and Bob with 5BTC out of the 10BTC total contained in the multisig address, Alice can make a 1BTC payment to Bob by updating the closing transaction to pay 4BTC/6BTC, where Alice is credited with 4BTC and Bob with 6BTC. Alice will give the signed transaction to Bob, which is equivalent to payment, because Bob can broadcast it at any time to claim his portion of the funds.
- To prevent an attack where Alice voids her payment by broadcasting the initial state of 5BTC/5BTC, there needs to be a way to revoke prior closing transactions. Payment revocation roughly works like the following.
- Alice must wait 3 days after broadcasting the closing transaction before she can redeem her funds. During this time, Bob is given a chance to reveal a secret that will allow him to sweep Alice’s funds immediately. Alice can thus revoke her claim to the money in some state by giving Bob the secret to the closing transaction. This allows Bob to take all of Alice’s money, but only if Alice attest to this old state by broadcasting the corresponding closing transaction to the blockchain.
Payment channels & revocable transactions
txn: Bob’s signature and a relative timelock (Bob’s spend branch); or Alice’s signature and a secret revocation hash provided by Bob (Alice’s revocation branch).
usually have multiple utxos. Once bob reveals his secret, alice can collect her spend TXO and rTXO.
revocable transaction script_pub_key: OP_IF # Bob’s spend branch - after the revocation timeout duration, Bob can spend with just his signature OP_CHECKSEQUENCEVERIFY OP_DROP OP_ELSE # Revocation branch - once the revocation pre-image is revealed, Alice can spend immediately with her signature OP_HASH160 OP_EQUALVERIFY OP_DROP OP_ENDIF OP_CHECKSIG
recovcation keys used base points and blinding key. similar to bip32, keys derived using base key.
BOLTs
BOLT is the Basics of Lightning Technology.
The BOLT repo found here describes the specification for the Lightning Network.
-
BOLT #0
Provides a basic glossary defining terminology that is used throughout the rest of the specification.
-
BOLT #1
Describes the base message protocol including the TLV format and the setup messages.
TLV is Type-Length-Value.
Funny enough, the unicode code point for lightning is 0x2607. In decimal, 9735 which is also the default TCP port.
-
BOLT #2
Contains peer channel protocol lifecycle.
A channel_id is used to identify a channel. channel_id = XOR(funding_txid, funding_output_index)
Before a channel is created, a temporary_channel_id is used which acts a nonce. This nonce is local and can be duplicate across the rest of the protocol.
-
Channel Establishment
-
Channel Close
-
Normal Operation
Once both nodes have exchanged funding_locked, the channel is used to make payments with HTLCs.
-
-
BOLT #3
Describes transaction and script formats.
-
BOLT #4
-
BOLT #5
Channels can end with a mutual close, unilateral close, or a revoked transaction close.
In a mutual close, local and remote nodes agree to close. They generate a closing transaction.
In a unilateral close, one side publishes its latest commitment transaction.
In a revoked transaction close, one party is cheating and publishes an oudated commitment transaction.
A commitment transaction has up to six types of outputs:
- local node’s main output: Zero or one output, to pay to the local node’s delayed_pubkey.
- remote node’s main output: Zero or one output, to pay to the remote node’s delayed_pubkey.
- local node’s anchor output: one output paying to the local node’s funding_pubkey.
- remote node’s anchor output: one output paying to the remote node’s funding_pubkey.
- local node’s offered HTLCs: Zero or more pending payments (HTLCs), to pay the remote node in return for a payment preimage.
- remote node’s offered HTLCs: Zero or more pending payments (HTLCs), to pay the local node in return for a payment preimage.
If the local node publishes its commitment transaction, it will have to wait to claim its own funds, whereas the remote node will have immediate access to its own funds.
-
BOLT #7
P2P
-
BOLT #8
-
BOLT #9
-
BOLT #10
-
BOLT #11
Invoice spec.
-
WIP: BOLT #12
BOLT 12 describes a new invoice format and flow called Offers.
The Draft of the PR can be found here.
The flow described is the following:
- Receiver publishes an offer.
- Payer requests a new unique invoice over LN using the offer.
- Receiver responds with a unique invoice.
- Payer pays the invoice.
There are a number of improvements over BOLT11.
Payment proof is designed to allow the payer to prove that they were the unique payer.
Merkle tree is used to be able to prove only specific fields of the invoice, not the enture invoice!
Some offers are periodic, meaning that payments are expected on a recurring period. This allows for new applications that require subscription-based payments.
Implementations
There are several implementations following the BOLT specification.
anecdotal example
Suppose Alice has a channel with Bob, who has a channel with Carol, who has a channel with Dave: A←>B←>C←>D. How can Alice pay Dave? Alice first notifies Dave that she wants to send him some money. In order for Dave to accept this payment, he must generate a random number R. He keeps R secret, but hashes it and gives the hash H to Alice.
Alice tells Bob: “I will pay you if you can produce the preimage of H within 3 days.” In particular, she signs a transaction where for the first three days after it is broadcast, only Bob can redeem it with knowledge of R, and afterwards it is redeemable only by Alice. This transaction is called a Hash Time-Locked Contract (HTLC) and allows Alice to make a conditional promise to Bob while ensuring that her funds will not be accidentally burned if Bob never learns what R is. She gives this signed transaction to Bob, but neither of them broadcast it, because they are expecting to clear it out later. Bob, knowing that he can pull funds from Alice if he knows R, now has no issue telling Carol: “I will pay you if you can produce the preimage of H within 2 days.” Carol does the same, making an HTLC that will pay Dave if Dave can produce R within 1 day. However, Dave does in fact know R. Because Dave is able to pull the desired amount from Carol, Dave can consider the payment from Alice completed. Now, he has no problem telling R to Carol and Bob so that they are able to collect their funds as well.
Alice knows that Bob can pull funds from her since he has R, so she tells Bob: “I’ll pay you, regardless of R, and in doing so we’ll terminate the HTLC so we can forget about R.” Bob does the same with Carol, and Carol with Dave.
Now, what if Dave is uncooperative and refuses to give R to Bob and Carol? Note that Dave must broadcast the transaction from Carol within 1 day, and in doing so must reveal R in order to redeem the funds. Bob and Carol can simply look at the blockchain to determine what R is and settle off-chain as well.
Lightning Conf 2019 Berlin
electrum slides on lightning Circular routes: send to self. Suggestions
- do not accept random peers
- disallow invoices to blacklisted pubkeys
Command line tools
- LNDmanage by @bitromortac
- Balance of Satoshis by @alexbosworth
- Rebalance-LND by @C-Otto
Make Me an Offer (Bolt 12) introduced.
LSAT
- Macaroon - cryptographic bearer credential
- Delegation possible
- Chained HMAC construction
- Secret root used to derive all others
- Fine grained permission
Hedging the Chain
- Bitcoin fee market
- “Every biz using the blockchain is inherently short blockchain fees”
- Derivatives traditionally used as a hedge
- Corn farmers inherently long corn
- They short corn futures as a hedge
Liquidity
- No pairwise trades
- different sources of liquidity is not the same
- Set outbound liquidity to the same fee
- Varied inbound liquidity
- Make liquidity a pairwise market
- External settlement mechanisms
- Circular rebalancing
Attacks
- Set min chan size …too many channels causes performance issues
- Create a bunch of hold invoices and drain balance
- Stealing free fees, someone sets up intermediate node between invoice and collects fees.
Discrete Log Contracts
Security
securing lightning nodes by devrandomlink to the lightning-signer project on GitLabkey mgmt
-
LSAT
Lightning Service Authentication Tokenlsat talk
using macaroon based bearer API credential with lightning network payment
-
Key management
Overview of each key in the channel lifecycle.
talk on key mgmt need onchain hot wallet to open channels (only need once)
1 of 2 keys must be hot for the funding transaction. If counterparty gets key, funds are lossed. If 3rd party gets it, they must collude.
Commitment secret: must be hot. Used to generate “local_pubkey” and “remote_pubkey” Used to derive subsequent secrets and public keys. If leaked, peer can steal all money in commitment txn.
Revocation basepoint secret: can be cold. Used to claim peer funds if they try to cheat. Can be cold if accessible before “to_self_delay”
If your counterparty gets access to this key, they can claim their funds in their to_local output immediately by circumventing the locktime
Payment basepoint secret: claim money from the “to_remote” output on peer commitment txn. can be cold if peer gets access to this key, all funds can be taken in the “to_remote”.
Delayed Payment Basepoint Secret: claim money on “to_local” output of commitment txn. can be cold.
HTLC Basepoint Secret: secret needed to sign for HTLCs. must be hot.
hosted channelsgist on hosted channels interesting idea but need to look more into security assumptions..
Privacy
An Empirical Analysis of Privacy in the Lightning Network
Routing
Routing involves routing a lightning payment through either a public or private channel.
Routing is generally constructed for a specified payment amount. Other considerations, however, includes value of open channels, decision to make new channels, re-balancing decisions, multi-path payments or multi-part payments (MMP, formerly AMP).
One of problem in routing is payment privacy. Two proposals to increase the privacy of paymnet senders and recipients are rendevous routing and route blinding.
-
Rendezvous Routing
Rendevous routing is a proposal aimed to protect the privacy of payments on the lightning network. In the initial proposal, an argument is made that private channels should not be revealed to payers. The solution is to have the payee choose one or more routes from certain third-party nodes on the public network to himself, and pass sphinx-encryped blogs for those routes to the payer. Then, the payer complets the route by finding routes from himself to the selected third-party nodes.
-
Route Blinding
Route Blinding is currently a proposal that aims to provide recipient anonymity by blinding an arbitrary amount of hops at the end of an onion path. Like rendezvous routing, this proposal is aimed and hiding the final portion of the route from the sender. The recipient chooses an “introduction point” and a route to himself from that point. The recipient blinds each node and channel for that route with ECDH. This blinded route and a hop-binding secret are included in the invoice.
-
Upfront Payments
Jamming attacks are possible where an attack can delay a payment resolution and therefore lock bitcoin along a route for a period of time. This attack is described here.
Fidelity Bonds are a solution to
Payments
Atomic Multi-path Payments (AMP)
Atomic multi-path payments allow a single logical payment to be sharded across multiple paths across the network. This is done at the sender side. Multiple subtransactions can be sent over the network and take their own paths and then the necessary constraint is that they all settle together. If one of the payments fails then we want them to all fail. This is where the atomicity comes in. This enables better usage of in-bound and out-bound liquidity. You can send payments over multiple routes, and this allows you to split up and use the network better. This is a more intuitive user experience because like a bitcoin wallet you expect to be able to send most of the money in your wallet. Without AMPs, this is difficult because you can only send a max amount based on current channel liquidity or something, which doesn’t really make sense to a user.
Only the sender and receiver need to be aware of this technology.
Splicing
With a splice-in, funds can be added to the channel, and they subsume an existing UTXO. And splice-out can remove funds from a participant balance and this creates a UTXO. You can take what’s in the channel, splice it off to an address that a person I’m trying to pay controls.
This removes the concept of my “funds are locked in the lightning network” because now you can do both on-chain payments into a channel and you can also do a payment out of a channel without interrupting the normal operation of the channel.
Submarine Swap
SF Bitcoin Devs Talk on Submarine Swaps
Submarine swaps allow you to pay someone on-chain and have the payment to them be contingent on them paying a Lightning invoice you give them. If they don’t pay the invoice, after a timeout you can get your money back.
Hold Invoices
Instead of immediately locking in and settling the htlc when the payment arrives, the htlc for a hold invoice is only locked in and not yet settled. At that point, it is not possible anymore for the sender to revoke the payment, but the receiver still can choose whether to settle or cancel the htlc and invoice.
Trampoline Payments
Lightning network currently relies on source routing where sender calculates the route. Sender needs to maintain graph state.
Trampoline payments is a new suggested way of outsourcing that aims at having lite clients outsourcing the route computation to trampoline nodes, nodes of higher Memory, bandwidth and computation power.
design decisions on trampoline routing
Static/Send/Spontaneous/Push Payments
Wow, lots of names for an overlapping concept.
OffersStatic PaymentsPush Invoices
HTLCs
HTLCs..Hashed Time Lock Contracts.
The initiator of a Lightning channel pays the closing fee. Lots of HTLCs = large fee. See thread.
Thread on free HTLC forwarding
An interesting idea to handling the edge cases around HTLCs is to have a firewall. An example.
PTLCs
Payment Pointsexcellent SuredBits blog on PTLCs
Future
challenges and opportunites for ln 2
Operations
The challenges of operating a lightning node deserves its own section. The lightning domain is distinct from on-chain bitcoin due to its own security assumptions, state changes, and end-user experience.
The most immediate concern is backup maintance. With on-chain bitcoin, one can is familiar with BIP39 mnemonic seed phrases as the ultimate backup for bitcoin. In lightning, the backup file is responsible for channels. Do not take backups of channel state itself. Inaccurate or revoked channel state is can lead to a justice transaction and punishment (loss of all funds in the channel). As a result, backups are tricky in lightning.
Static channel backups (SCBs) are the best backups for lightning node operators. The backups are called static because they are only obtained once - when the channel is created. Afterwards, the backup is valid until the channel is closed. A SCB allows a node operator to recover funds that are fully settled in a channel. Fully settled funds are bitcoin in commitment outputs, but not HLTCS.
Automating channel backups for LND
Subscribe to channel backups for LND
In addition to backups, channel management is a large area of focus. A node operator wants to be connected to reliable and honest peers. Factors to consider are uptime, balance, and cost of rebalancing. It is convenient to create a list of decent nodes and maintain a relationship with them. For inbound liquidity, swaps can be used or swap services like Lightning Labs Loop. Loop can be used to refill channels. Managing incoming channel requests can be important in order to prevent undesirable peers. For example, setting a threshold for channel capacity can prevent dust limit problems in the future. It is better to have fewer channels that are well capitalized than many channels with poor capacity.
Watchtowers can be used to monitor private nodes.