The Simple Lightning Newsletter

Payment Timeouts in Payment Channels - #3 Timelocks

2022-03-31T00:02:00+00:00

This the third post in our 3-part introductory series on payment channels!

In the last deep dive, we talked about how hashlocks work to create atomic payments in payment channels. In this post we’ll go into timelocks, the second type of locks used to construct HTLCs. Timelocks establish timeouts for payments and enable trustless escrow services in the Lightning Network.

Timeouts with Timelocks

So, why do we need Timelocks in multi-hop payments?

Time is money, and without being able to account for time it’s impossible to process payments.

Imagine, you have payment route with four hops in the route: (1) Alice, (2) Bob, (3) Charlie, and (4) Dave.

Fig. 0. Four peers with 300k Sats between each of them.

In the last post we showed how Dave generates the random secret preimage (usually abbreviated as “R”, but represented here as a key) and computes the hash (represented here as an “H” lock) to send to Alice. Alice locks up funds in HTLC with Bob, Bob does the same with Charlie, and Charlie with Dave. The result is Fig 1, with 100k sats locked in an HTLC with each peer in the route.

Fig. 1. Each hop in the route has 100k sats in an HTLC with its peer.

However, these HTLCs don’t have any timelocks.

What happens if one of the nodes in the route crashes or goes offline?

Without timelocks, payments can get stuck.

Transactions are only atomic between hops, not for the route as a whole.

Consider what happens if Bobs’ node goes down after Dave received his hashlock from Charlie (Fig. 2). Dave has the key that allows him to unlocks the hashlock, between him and Charlie. Dave sends the key to Charlie who in turn sends the key to Bob. However, Bob doesn’t respond because his node is offline.

But if Bob doesn’t respond, Charlie is still able to use the secret to retrieve the funds from Bob by settling on the blockchain. Using the secret, Charlie will close/fail their channel, by sending the last HTLC contract/commitment transaction to the blockchain.

But what happens to the funds between Alice and Bob?

Fig. 2. Bob's node goes down and Alice's 100k Sat payment is locked, until Bob comes back online.

Alice is the one who requested to make this payment, so she’s not expecting to her money back. However, it doesn’t benefit anyone to have BTC stuck in a state where no one can move or claim it.

Alice could wait until Bob comes back online and is responsive again, which could take days, weeks. But what happens if Bob dropped off the graph and never responds again? The HTLC between them is valid indefinitely, so the money committed to the HTLC could stuck there permanently.

What are Timelocks?

Timelocks are the other half of the condition inside of HTLCs.

HTLCs are hashlocks + timelocks, combined with an OR condition. The funds in each channel can only flow one way, forward to the recipient if hashlock is unlocked or backward, back to the sender if the timelock times out.

Fig. 3. Hashlocks OR Timelocks in an HTLC

To receive/unlock payment in a HTLC, the recipient can either provide the key for the hashlock OR wait for the timelock to expire. If the hashlock is valid it can be executed in the payment channel or onchain, however the timelocks are only ever executed on chain as a fail safe.

How do timelocks “unstick” payments?

Timelocks require that parties in the contract acknowledge a deadline and agree to forfeit the ability to claim the payment, returning funds to the payer after a specific time and date.

Fig. 4. A visualization of timelocks added to each of the payment channels compared to Fig. 2. to create an OR condition between the hashlocks and timelocks.

Another way to think about this is that, the timelock dictates how long Bob has to beat Alice and provide the secret. If Bob produces the secret before the timelock unlocks he can claim the funds, but if the timelock times out first Alice can. And the same goes for Charlie vs. Bob, and Dave vs. Charlie.

If Bob goes offline after Dave received his payment from Charlie, Dave can still claim the funds from Charlie, who will in turn try to claim the funds from Bob. Bob has the time remaining in the timelock to comeback online and claim his funds from Alice. Because the Charlie’s transaction is on the blockchain, the secret has been made public and can easily be found. If the funds aren’t claimed, after the deadline of the timelock Alice will be able to retrieve those funds, and Bob is the only one out the money (Fig. 5.).

Fig. 4. The HTLC being unlocked by the timelock between Alice and Bob.

How Do Payment Channels Make Up The Lightning Network? - #2 Hashlocks

2022-03-16T00:02:00+00:00

This the second post in our 3-part introductory series on payment channels.

In the last deep dive, we talked about how a 2-of-2 multisig is used to move bitcoin off of the main chain and into a payment channel. In this post we’ll go into how payments can be routed though multiple payment channels in the Lightning Network.

Payment Channel Basics:

Fig. 1. The basic terminology on payment channels

Users and businesses on the network operate as lightning nodes, two nodes can transact peer-to-peer to move funds in a payment channel between them without having to incur fees that may one day become prohibitive on the Bitcoin blockchain.

But one peer-to-peer payment channel in isolation is not much of a network.

How are payment channels connected to create the full Lightning Network?

Fig. 2. Nodes aconnected via payment channels in the lightning network

Peer Connections and Channels

Nodes talk to each other through the TCP/IP layer of the internet, and connect to each other by establishing payment channels on the Lightning Network. Although you can open as many channels as you want, every open channel costs some amout of on chain fees, and requires tieing up some liquidity.

On the Lightning Network, users don’t need to open a channel with every user they want to transact with, because transactions can be routed through other peers.

But how do payments route through nodes across the network?

Routing and Receiving Payments

Fig. 3. A Single-hop Payment routing through nodes A, B, and C.

Say Node A in the A-B-C connection wants to send 100k Sats (or about $50) to Node C with 1 hop in the route (Ct. Fig. 4).

How does the protocol enable the payment to go through the middle man (Node B) trustlessly?

Fig. 4.

Alice can’t blindly trust Bob to pass the payment to Charlie without putting some security measures in place first.

What is a Hashlock?

In Bitcoin hashes are used in a variety of different ways, full nodes use it to validate data, link together blocks in the chain, and miners use it to prove they’ve done work for the rest of the network. In this instance, hashes are used to create a lock.

A hashlock is a cryptographically hashed or scrambled random number:

Fig. 5.

SHA-256 is a one-way mathematical hash function that creates an unique output. We can mathematically prove that it’s impossible to guess or reproduce the original number from the output hash. Because of this property, the hashed output can function as a lock, and the original input can serve as the key.

The user that generated the lock can give it to other users for the purpose of locking up bitcoin. To unlock the bitcoin, the user just provides the secret key. Revealing the key in a transaction, shows everyone how to reproduce the unique hash.

Trustless Payments Channel Routing With HTLCs

Here the specific hashlock being used is called an HTLC. Hash Time Locked Contracts (HTLCs) are conditional payments used in payment channels, and are the fundamental building blocks of every payment on the Lightning Network.

Sticking with this example, Alice wants to send 100k Sats to Charlie, but the two of them don’t have a direct channel relationship, and it’s more bitcoin than either of them want to spend to open a new channel. Conveniently, they both have 300k Sats channels with Bob, so the payment can route through him.

First, Charlie generates a random number as the secret key and computes its SHA-256 hash represented as the lock. Then he sends the hashlock to Alice.

Fig. 6.

Alice uses her payment channel with Bob to pay him 100k Sats, but she adds the condition that the key for Charlie’s hashlock is needed to claim the funds. In order for Bob to claim the payment, he has to provide the secret data which was used to compute the hash.

Fig. 7.

Bob keeps his payment from Alice, and generates his own 100k Sats payment to Charlie. Using the hash provided from Alice Bob locks his 100k Sats payment, creating the condition that the key is needed to claim the funds. Using his payment channel to Charlie, Bob sends the payment along.

Fig. 8.

Charlie has the original key (usually called the preimage) that was used to produce the hash, so when Charlie receives the payment from Bob he’s able to lock and claim the funds. By making this transaction the secret is revealed to Bob, so that he can also claim his payment from Alice.

Fig. 9.

With HTLCs the capacity of each of the two channels don’t change, only move from peer-to-peer. The purpose of HTLCs is to make atomic payments, so that the peer-to-peer transaction isn’t divisible into separate parts.

Spec Meeting - 14.Mar.2022

2022-03-16T00:01:00+00:00

The call this week was mostly a technical discussion on how shutdown should work with cooperative close peer messages.

Open Pull Requests

#968 - Port convention for different network
- Litecoin is not supported. No need to specify Litecoin ports.
#967 - Blinded fees
- Still some debate on if the this is being done correctly.

Spec Meeting - 02.Mar.2022

2022-02-28T00:01:00+00:00

The Lightning Network has multiple implementations that are all theoretically working together to be compatible and define the network as a whole. But the past week there have been some public discussions around how relevant the Lightning Spec process actually is. Some developers believe everything should be formalized into the Spec, others want to maintain control of what features they offer/implement and when.

Current disagreements aside, hopefully things evolve to produce the best experience for users.

Open Pull Requests

#960 - Echo channel_type in accept_channel
#962 - Remove legacy sphinx format
#964 - Clarify mutual close requirements
- BOLT 2 Clarification
#759 - Onion messages
#910 - Simple turbo channels enablement

We skipped the deep-dive for the week due to upcoming conferences. If you want to contribute or get involved by joining in on the spec calls or writing content shoot over a DM on Twitter.

How Do Payment Channels Work? - #1 The Basics

2022-02-16T00:02:00+00:00

This the first post in our 3-part introductory series on payment channels.

The Cost of On-chain Transactions

In the Bitcoin network, nodes are distributed all over the world, and the transaction data is synchronized across the network in blocks. Because this is a 10-minute process, users on the network also wait 10-minutes for their transactions to be confirmed. Bitcoin is not directly limited to a specific number of transactions per second, but it is indirectly limited by the maximum capacity of transaction weight per block.

The storage on the blockchain is a scarce resource, which is why users bid for their transactions to be confirmed in that next block. When there are more transactions waiting to be confirmed in the mempool, fees on-chain rise to match the increased demand for inclusion of their transaction on the chain.

For the network, every UTXO is data that each fully validating node is required by law to store. For the user, the price is 10-min processing and transaction fees.

What if we could get closer to instant payments, with less fees?

What are Payment Channels?

Payment channels, sometimes referred to as micropayment channels, are a trustless method of exchanging funds peer-to-peer. On the Bitcoin network, payment channels lock funds into a 2-of-2 multi-signature address that allows the two parties to exchange bitcoin off of the blockchain.

As bitcoin scales, more users will opt to transact their bitcoin in payment channels to opt out of on-chain transaction fees.

For more on the history of payment channels check out Christian Decker’s Chaincode Lightning talks.

How do Payment Channels Work?

Channel Open: The Funding Transaction

To open a channel a transaction a 2-of-2 multi-signature is made to lock up funds.

If you want to open a channel with your local pizza stop, Homeslice Pizza, you can commit 1,100,000 sats or ($500 USD) to the channel by sending the funds to a 2-of-2 multi-signature anchor or funding transaction. The funds are essentially locked because you and Homeslice both have to sign a new transaction in order to release the funds.

The funding transaction must be sent to the bitcoin network and confirmed in order for the channel to be opened.

Payments in the Channel: Commitment Transactions

Once the channel is open you can sign new transactions to make changes to the balance.

Over the next weeks, as you make new orders to Homeslice you credit your balance by 110,031 sats and debit Homeslice’s balance by 110,031 sats.

Both parties mutually sign each commitment transaction, which updates the balance of the channel.

These transactions are considered valid and could be sent to the network, but instead, the parties can also keep these transactions off-chain. This way, the balance state of the channel can be updated thousands of times getting us closer to instant micropayments.

Instead of being limited by block weight, users in payment channels are theoretically only limited by how fast both parties can create and sign a commit transaction.

To ensure that neither party tries to cheat, by broadcasting an old state of the network, all old transactions are invalidated. When a new commit transaction is made, both parties invalidate the previous state of the channel. In the event of a conflict, only the newest commitment transaction is considered valid to the network.

Channel Close: The Settlement Transaction

When you and Homeslice pizza are in unanimous agreement to close the channel, one party sends the settlement transaction to the blockchain. This way, only two transactions ever hit the bitcoin blockchain, and the users get to minimize fees.

But this is not the typical payment channel, there are a few problems here.

Problem #1 - Locked Liquidity is Expensive

Although users save money in the long run by minimizing fees, payment channels require a lot of liquidity up front. And profits in the channel are indefinitely locked up.

Problem #2 - Directionally is Limited

In our example, where you are the only peer to fund the channel, there is no initial balance for Homeslice Pizza to make payments to you. Not that they have a reason too, but their business does have inventory that they need to pay for.

What if they could make payments to one of their vendors with the funds locked up in your payment channel with them?

What if there was a way to move funds from an open channel to a 3rd party without hitting the blockchain?

What is the Lightning Network?

The Lightning Network is a network of nodes connected by multiple payment channels! In the following posts in this series, we’ll level up our understanding on payment channels, and how they constitute the network as a whole.

Spec Meeting - 14.Feb.2022

2022-02-16T00:01:00+00:00

This week there were no merged pull requests. Much of the discussion was focused on long term open pull requests.

We are exploring how to better communicate the updates to pull requests in the event that spec meetings are primarily, deeply technical and less eventful.

Open Pull Requests

#904 - Use a warning in quick close
- Added helpful context in debug logs
#798 - Offers
- Added Offers functionality for use with or without Blinded paths
#910 - Simple turbo channels enablement
- Added “channel_ready message”- Zeroconf enables channel usage immediately prior to transaction confirmations onchain. Information in the “funding locked message” is not available yet: the short-channel-id is missing because it’s a reference to the funding tx onchain (doesn’t exist yet). By using an alias SCID until the funding transaction is confirmed, peers can switch over to using either the alias or the real SCID. Therefore, channel readiness is independent of the funding transaction confirmation.

What is Bitcoin Dust & How Can We Fix It?

2022-02-02T00:02:00+00:00

How is dust created?

Bitcoin is represented as Unspent Transaction Outputs (or UTXO’s). You can think of UTXO’s as the unit of Bitcoin that is transferred inside of transactions. The lifecycle of a UTXO begins in a “coinbase transaction” when miners earn bitcoin for correctly finding the Bitcoin’s next blockhash. When a mining pool earns the bitcoin from a coinbase transaction, the reward is split up to pay miners that were contributing to the pool’s hashrate. Because the value being sent to each node is small, some pools may set a minimum balance before it transfers.

UTXOs split into smaller values:

Whenever Bitcoin is sent from the pool, a single UTXO has to be split, to create change. Each full node in the network has to keep track and store the total UTXO set. Because this contributes to the growing size of the blockchain, we want to limit the number of UTXO’s in the set.

What is dust?

Each UTXO has its own transaction chain of history going back all the way back to when it was first mined into existence as a coinbase transaction. As UTXO’s get divided into smaller and smaller values of bitcoin, more UTXO’s are added to the set and the value of bitcoin within them gets smaller and smaller. When a user wants to spend a UTXO containing a small value of bitcoin it at some point no longer makes economic sense to do so. The value of bitcoin in the UTXO is so small, it isn’t enough to pay for the transaction fee required for bitcoin full nodes to relay it or for miners to include the transaction in a block. This is precisely when these UTXO’s are referred to as dust. Dust is essentially low value UTXO’s that have collected over time and have been outpriced or uneconomical to spend.

Why does dust put a strain on the network?

The mempool is the default 300 megabyte database of unconfirmed or pending transactions which is stored and unique to every node. But it is also a competitive marketplace for confirmation, when there is a backlog of unconfirmed transactions fees are relatively high, and when there is no backlog transactions fees are much lower. When fees are low, it may become economical for those who have dust UTXO’s to consolidate their sent into one large UTXO, which would also be good for the network as a whole.

If every Bitcoiner used on-chain Bitcoin transactions to buy $3 coffees, the UTXO set would dramatically increase in size. This also has adverse effects and negative network externalities such as increasing the RAM and disk space hardware requirements required for “pruned nodes” (fully validating nodes that don’t store the entire blockchain). Enter the Lightning network!

Dust on the Lightning Network?

Bitcoin used in payment channels allows for much more frequent and smaller transaction values in theory because of the need to only create new UTXO’s when a channel is opened or closed (transaction mined on-chain). OG Bitcoin artist CryptoGrafitti, put this theory to the test with a “lowest bid auction” in 2018, whoever paid the lowest would receive his Black Swan piece. There is no such thing as dust on the Lightning Network now, however, it’s commonly believed that routing fees on the Lightning Network will increase over time, so payment amounts will also once again need to increase to remain economical to be routed. Otherwise, a direct payment channel relationship with a peer is required.

What Is a Dust Attack?

Now that we’ve explained dust, lightning transactions, and UTXO’s, you can see where reality collides with theory when we approach this from an adversarial perspective. In 2017, it was widely believed certain mining pools were doing a DoS (Denial of service) attacks on Bitcoin by flooding the mempool with transactions to bid up fees and make less value UTXO’s uneconomical to consume. When this attack happens, a miner is able to include their dust UTXO’s in blocks because they can mine their own transactions without needing to communicate with nodes that wouldn’t relay them.

Chain surveillance companies will also do “dust attacks”, effectively tracing someone’s UTXO lifecycle by sending them small UTXO’s they accidentally consolidate with their other funds.

Last year, Antoine Riard disclosed a Lightning network vulnerability related to dust. Because the “dust limit” is enforced by a transaction relay policy between Bitcoin nodes, a Lightning commitment transaction (or channel update) with one of its UTXO’s below the dust limit may fail to relay in the event of a unilateral transaction. The CVE’s could have been exploited via fee blackmailing of node operators, liquidity burning of competing LSP’s, or attacking direct channel peers if the lightning node operator was also a miner.

The Future of Micropayments on Lightning

Many believe the Lightning Network to be the holy grail for “micropayments”, but it’s still unclear whether that is true due to the long term economical feasibility. This is because of the 546 satoshis dust limit default relay policy on-chain enforced by Bitcoin node operators as well as the 483 max HTLCs in flight, base fee, and ppm fee routing policies off-chain enforced by Lightning node operators. Time will tell whether the capital allocation requirements of opening and closing a channel will surpass the average Lightning Network user’s Bitcoin hot wallet threshold. All eyes are on the mempool–may the best transaction snipers win. This topic will serve as a foundation for our future Replace-by-fee, Child-pays-for-parent, zero confirmation, and package relay related deep dives.

1 sat/vbyte or bust,
- Seardsalmon

Spec Meeting - 31.Jan.2022

2022-02-02T00:01:00+00:00

Light meeting this week.

Merged Pull Requests

#954 - Clarify the sighash types for HTLC Success and Timeout transactions
- This was a small change for clarification and cross reference.

Open Pull Requests

The two open pull requests have been unbundled to focus on finer details, allowing for more time and scrutiny on individual parts. It is expected that Offers features such as route blinding will be adjusted and released in phases.

#765 - Route Blinding
#798 - Offers

BOLT 11: How to Pay People on Lightning

2022-01-19T00:02:00+00:00

Before doing a deep-dive on the more topical BOLT 12 and how future payments could help improve payments on lightning, we should first explain how payments currently work with BOLT 11.

Bitcoin Address vs. Lightning Invoice

BOLT 11 is the formal definition on how to pay people over lightning, similar to how transaction outputs and address types define how bitcoin is sent over the Bitcoin blockchain. When you make payments on (layer-one) Bitcoin you generate and share an address to the payee. With (layer-two) Lightning the difference is, the payee requests an invoice from the payer, and that invoice expires if it’s not paid within a specified time.

Bech32 Encoding for QR Codes

From a user experience standpoint, this means you’re presented with a unique QR code containing a BOLT 11 Invoice at the point of payment instead of providing one. The invoice is created with the same bech32 encoding that was previously used in SegWit, which was designed to error correction when addresses are typed and make the robot vomit of QR codes compact.

You’ll notice that the invoice is much larger than the address because bech32 in SegWit encodes a simple hash. And for Lightning Network usage bech32 encodes an entire payment invoice, which is why the invoice QR codes also look larger and more complex.

Decoding BOLT 11 Lightning Invoice Data

When decoding the BOLT 11 invoice we have two parts:

1. The Human-Readable Data

2. The Machine Data

2.2 The Tagged Fields

Defined tags are optional fields for adding a payment hash, invoice description, expiry time, public key of the payee node, a fallback bitcoin “onchain” address, extra routing information for routing to an unannounced channel, payment metadata, a payment secret to prevent probing by other nodes, and more. Each field has its own: type, data_length, and data section for formatting purposes. But knowing the details of all this data is not as important as understanding the motivation for updating this.

Problems With BOLT 11

There are some problems with BOLT 11, and particularly bech32. Bech32 encoding was used because it was familiar to SegWit, but it makes invoices that are so large and clunky to send inside the lightning network it’s not the best user experience. Secondary to that, the encoding was found to have mutation issues meaning that it will have to be replaced anyway. In a future post, we’ll cover more about BOLT 12 offers and how developers can fix some of the existing issues with BOLT 11 invoices.

Aside from BOLT 11, there are other optional ways you can pay people over lightning using Keysend, LNURL, MMP / AMP, and with Lightning address, which we will cover in future deep dives as well.

Spec Meeting - 17.Jan.2022

2022-01-19T00:01:00+00:00

There were two pull requests merged: Informing peers about an IP address change and facilitating peer communications before unilateral closes. The IRC meeting was cut a bit shorter than usual due to the US Holiday.

Merged Pull Requests

#917 - BOLT 1: adds remote address to optional init_tlvs (IP discovery)
- This notifies a peer when its IP has changed so that it can inform its other peers of the change as well.
#942 - Removed requirement to broadcast an outdated commitment transaction
- Instead of immediately unilaterally closing a channel upon discovering that a peer is unable to provide the most up to date channel balance state, this allows the peer other options to recover the state or wait for the peer to send an error before unilaterally closing.

Open Pull Requests

#910 - Explicitly allow funding_locked early, and support alias scids
- No second implementation yet. This would allow channel peers to acknowledge payments using an alias until a short channel id is confirmed onchain at a “funding depth of zero”. This is an intended UX improvement for rapid onboarding of new users. They can receive payments on Lightning instantly without needing to wait for multiple blocks onchain to set up a lightning channel. It is a nuanced topic with many risk tolerances and UX tradeoffs which we will explore in a future deep dive.
#911 - BOLT 7: add gossip address descriptor type DNS hostname
- This allows node operators to announce a symbolic name such as a domain name to remain reachable despite an IP change.
#919 - Add a max_dust_htlc_exposure_msat
- No second implementation yet, just needs cross implementation check. This limits the amount a miner would earn in the event of a unilateral close to a max dust amount plus transaction fees. It caps the amount that is not explicitly associated with one of the channel peers or an HTLC that would be used as fees.
#941 - Clarification how messages are referred to
- A clarification to BOLT 1 messages.