Abstract: When making low value payments on the lightning network, especially in “high” onchain fee environments, the security benefits of the lightning’s HTLC system may be somewhat limited. This problem may only be applicable in a limited number of scenarios, namely while the payment is in-flight and mainly for payment routers. Quantifying the magnitude of this problem can be quite complicated, as it depends on the specifics of the channels involved. However, while interesting in theory, the issue is perhaps not as significant as the more simple problem of channel counterparties griefing each other with expensive non-cooperative channel closures, regardless of any low value in-flight payments.
The Problem With Low Value Lightning Payments
Recently, on Twitter, some have suggested that lightning payments might not be trustless for small amounts. This is because in-flight payments are protected by Hashed Timelock Contracts (HTLCs) and if the HTLC costs more onchain when used, than the value being protected, perhaps the lightning network is no longer trustless. This issue does not only occur if the HTLC costs more in onchain fees than value being protected, but even when the onchain fees are significant. For instance, a user losing half their money in fees to protect a payment may also be unhappy. This issue can be referred to as the uneconomical HTLC problem.
This issue may be of concern, because low value payments were supposed to be one of the core use cases for lightning. Indeed, lightning is said to be unsuitable for large value payments because it may be too difficult to find the liquidity. In an environment with “high” prevailing Bitcoin transaction fees, say of 30,000 sats for a typical transaction, this could mean one can not securely spend less than 30,000 sats using lightning, which could be a major weakness. This could mean lightning is only useful for “medium” value payments.
Some Tweets articulating this problem are available below:
When The Problem Applies
The first way to approach this problem is trying to establish exactly when this problem applies. The problem only occurs when payments are in-flight. Once a lightning payment has been settled and the commitment transactions have been updated, the payments are secure and HTLCs are not required. Even payments as low as 1 sat can be thought of as secure, as long as they are settled. A multi-hop payment is also necessary, since the security benefits of HTLCs only apply to multi-hop payments. HTLCs are still technically used for single hop payments, to keep the payment flow system as similar as possible and reduce complexity, but HTLCs only provide added security in the event of a multi-hop payment. This uneconomical HTLC issue therefore only really applies to the payment router. The sender is trying to spend funds, so does not rely on the HTLC for protection. Likewise the final recipient either receives the payment or they don’t. And of course, even when the problem of uneconomical HTLCs arises, the payment will still work just fine most of the time. It is just that the router is at risk of being griefed, if the other parties are trying to troll them and waste their resources. The attacker does not benefit from this themselves, so there is no major incentive problem, it is just an opportunity to troll other users of the network.
Please see below a diagram of a 4,000 sat payment from Alice to Charlie, routed via Bob. If the prevailing market fee rate is “high”, for instance 50 sats/vB, if Alice goes offline while the payment is in-flight, the HTLC protecting Bob may be uneconomical to use. For instance, redeeming the HTLC output may consume around 100 virtual bytes of blockspace, at 50 sats/vB, that is 5,000 sats. This compares to the output value which is only 4,000 sats. Therefore, Bob would lose 1,000 sats if he could sweep up the UTXO. In reality of course, Bob may not sweep up the UTXO and the output may just sit there indefinitely. It is easy to see why the HTLC did not really add to Bob’s security and why routing 4,000 sats is insecure.
The above description of the problem is an oversimplification. The reality of the problem is more complex and difficult to analyse, and requires some knowledge of HTLCs and lightning channel construction. Actually, this 5,000 sats redemption cost may technically be the wrong cost to consider.
Illustration of a successful lightning transaction with HTLCs
In the above scenario, when in-flight payments are insecure, the roles of the three parties are as follows:
- Alice is the attacker
- Bob is the victim
- Charlie is fine either way
In a high fee environment, if the payment fails, Bob is likely to have to pay a lot of money in fees to close the channel anyway. The extra money spent on the HTLC is going to be low by comparison. Therefore, this attack is largely theoretical and not particularly significant. The main problem is that high fees can make non-cooperative channel closures expensive. This attack can be thought of as a subset of that wider problem.
In the example above, Alice is supposedly attempting to pay Charlie 4,000 sats, via Bob. In this attack scenario, Alice decides to grief Bob by refusing to complete the HTLC in the final step. Bob now has to initiate an expensive non-cooperative channel closure transaction in his channel with Alice, with an extra HTLC output of 4,000 sats. Bob has paid Charlie 4,000 sats and if he does not get paid by Alice, he loses money.
Who Pays The Onchain Fees?
To properly understand this problem, we now need to consider all the transactions involved and who pays the onchain fees. The first transaction is the non-cooperative channel closure. The fees for this transaction are paid for by whoever opened the channel, which could be Alice or Bob. If Alice opened the channel, then the uneconomical HTLC problem does not apply here, since Bob (the victim) isn’t paying the fees associated with the HTLC output, and therefore the HTLC still protects him. Alice is therefore not likely to even bother initiating this attack if she was the one who opened the channel.
If Bob opened the channel and therefore pays the fees, it could be necessary to break this fee payment down into two components. There is the original part of the fee and an extra part of the fee needed to pay for the extra HTLC output. In theory, this original part of the fee is not part of the uneconomical HTLC problem, because it would have had to be paid anyway, regardless of the low value lightning payment. Alice could have just done a forced channel closure anyway. However, when the HTLC was set up, a new commitment transaction was agreed, where some funds were deducted from the amount going back to the party who opened the channel, this is in order to pay for the extra HTLC output. The HTLC output is around 32 bytes, therefore this extra fee could have been around 3,200 sats (Assuming a prudent 100 sat/vB fee rate). Therefore, if Bob opened the channel, you could argue that there is no HTLC protection when routing a payment below 3,200 sats. We argue that this is the core of the uneconomical HTLC problem. In our example, Bob is still a net beneficiary of the HTLC, since the payment value was 4,000 sats, therefore he makes a “profit” of 800 sats. Therefore the HTLC may provide some security, but Bob is not likely to be especially happy.
Who pays the fees? | Uneconomical HTLC problem | |
| The original non-cooperative channel closure onchain fee | The fees for this transaction are paid by whoever initiated the channel opening. This could be Alice or Bob. | While this transaction has high fees and is expensive, since there is no extra cost associated with the HTLC, this transaction does not contribute to the uneconomical HTLC problem. The fees here can be considered as sunk costs. |
| The extra fee in the non-cooperative channel closure for the HTLC output | This fee contributes to the uneconomical HTLC problem, it is an extra cost incurred as a result of the HTLC. However, this only contributes to the problem if the victim pays. | |
Redemption of the HTLC output | The fees are paid for by the “victim” of the uneconomical HTLC attack. (i.e. Bob) | These transaction fees may contribute to the uneconomical HTLC problem, depending on how the problem is analysed. (See the next section) |
Redemption Of HTLC Output
There is also a second transaction involved in this problem. Bob is going to need to redeem his small HTLC output at some point in the future to consolidate it with the rest of his funds. There will also be fees associated with this transaction and Bob is likely to make an overall loss in our example. These fees are likely to be a lot larger than the extra amount added to the commitment transaction to include the HTLC output, 5,000 sats as calculated above. When these fees are considered, in our scenario, it could mean Bob is not protected by the HTLC for lightning payments of up to 8,200 sats. However, whether these fees should be included in the uneconomical HTLC problem is less clear.
One reason to exclude these redemption costs from the uneconomical HTLC problem is that onchain fees may go down in the future. Bob may still be in profit from the HTLC, as long as he is patient. He could patiently wait for fees to fall and then consolidate the output. Or maybe he could find a good samaritan miner willing to include his consolidation transaction in a block, for a low fee. This miner could be trying to benefit Bitcoin by reducing the size of the UTXO set, miners have produced blocks like this before. Or maybe at some point in the far future, Bitcoin will upgrade the consensus rules, with a focus on reducing the UTXO set, turning dust UTXOs into spendable coins. Our point is that even if the HTLC seems uneconomical when the channel closes, this may change in the future. Therefore the HTLC may provide some limited security benefits and Bob may get some satisfaction knowing that he has a 4,000 sat UTXO sitting there. It is better than nothing.
Uneconomical HTLCs Can Still Be Helpful
In lightning, Bob (or protocol designers) have two choices for dealing with these low value payments, create this uneconomical to redeem HTLC or have no HTLC at all. Just because the HTLC is uneconomical and results in losses for Bob, it does not necessarily follow that the HTLC is useless. In the above example, one can argue that Bob’s HTLC may have worked, at least to some extent, even though he may have lost money. The uneconomic HTLC may still have helped deter attackers.
Consider the following example. What if you are walking on the street and a criminal approaches you threatening to attack you if you don’t hand over your wallet. Your wallet contains US$100 in notes. You also have a hidden panic button on you, that alerts an elite private security force, which can swoop in by helicopter and save you. This service costs US$1,000 each time you use it. Would you press the button? If you press the button you still have your original US$100, but you are out of pocket US$900, having spent a US$1,000 fee for the service. Even though you lost money, the security system can still work and you can deter future attackers. Your original US$100 is still safe. Of course many will not agree that this analogy is appropriate. The biggest weakness being that the successful street thief could get to keep the US$100 in cash. In the lightning network attack, the perpetrator (Alice) gets nothing. Therefore, instead of a typical thief, imagine more of a sadistic bully type character, demanding you hand over your wallet so they can burn the money in front of you. In this contrived scenario, would you still press the panic button and pay $1,000? Of course, we are open to the criticism that our analogy here is somewhat stupid and inappropriate. In the real world you don’t want to be attacked, while on lightning only money is at stake, you don’t care how you lose it or which type of funds you lose.
There is at least one scenario when the uneconomical HTLC provides a more concrete example of protection. What if Alice (The attacker) is also a large miner. If no HTLC output is produced at all, this 4,000 sats is added as a fee to the miner. This is extra marginal income, since the transaction size of the commitment transaction is unchanged, but the fee is higher. There is therefore an attack scenario where a large miner becomes a lightning user, only to steal HTLCs. The uneconomic HTLCs do help deter this attack. On the other hand this attack is unlikely to materialise, because the value of payments at stake will be necessarily low, probably not significant for a large miner.
In our view, in our example Bob is not any worse off by having the HTLC output. The only downside to Bob is the extra 32 bytes the HTLC output adds to the channel closure transaction, which he only pays for if he opened the channel. Therefore, even though the uneconomical HTLC problem is real for low value payments, from a protocol design perspective it might still be worth having these HTLCs. The alternative, no HLTC at all, is even worse.
Bitcoin Core Dust Relay Limits
Above we explained why it’s worth keeping HTLCs, even when it’s uneconomical to redeem the output. However, what if the value you are sending over lightning is so low, for example 1 sat, that it’s below the Bitcoin dust relay limit? In this scenario, your lightning node will not even create an HTLC for you. An HTLC output cannot be created, because Bitcoin Core nodes would not relay the transaction. The transaction with a 1 sat output could still be valid according to Bitcoin’s consensus rules, it’s just a non-standard transaction so will not be relayed.
Bitcoin Core has a transaction relay dust limit fee rate of 3 sats/vB. A transaction with a fee rate below this level will not be relayed, because of this spam prevention feature. This per transaction limit is not necessarily a problem for HTLCs, the commitment transaction can have a fee rate higher than 3 sats/vB, even when there is a 1 sat output. Bitcoin Core also has relay rules for the minimum value of an output, for it to be relayed. A P2WPKH output is around 31 bytes in size and will consume around 67 virtual bytes to spend, which is 98 virtual bytes in total. Therefore the dust limit for the value of a P2WPKP output is 294 sats (3 x 98). For a lightning output, this limit may be a bit higher, as it’s a 2 of 2 multisignature spend.
This means that for in-flight payments below around 500 sats, the router should consider the payment as trusted. This is a much stronger manifestation of the problem as there is no HTLC protection at all. Prevailing market fee rates do not actually matter here at all either. It doesn’t matter if the market clearing rate is 1,000 sats/vB or 5 sats/vB, the dust relay limit caused the issue. The lightning protocol does allow node operators to specify a minimum HTLC size, which can be modfied depending on prevailing market onchain fee rates.
Removing The Dust Limit
Some people have argued for removing the dust limits for various reasons. For example Bitcoin developer Jeremy Rubin listing five reasons to remove the dust limit below:
- it’s not our business what outputs people want to create
- dust outputs can be used in various authentication/delegation smart contracts
- dust sized htlcs in lightning force channels to operate in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in various jurisdictions; agnostic treatment of fund transfers would simplify this (like getting a 0.01 cent dividend check in the mail)
- thinly divisible coloured coin protocols might make use of sats as value markers for transactions.
- should we ever do confidential transactions we can’t prevent it without compromising privacy / allowed transfers
Source: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
Please note reason three above. Increasing security for low value payments in lightning is cited as a reason to remove the dust limit altogether. Removing the dust limit could increase security for low value lightning payments. However, this security benefit here is limited, at least when market fee rates are above 3 sat/vB, because while the low value HTLCs could now be relayed, the outputs would still be uneconomical to redeem.
Jeremy’s proposal to remove the dust relay limit proved unpopular among some developers. The argument veered towards the 2014 OP_Return debate and the 2023 Ordinals debate, as to whether Bitcoin is only for “financial transactions” or if the system should have other uses. This has even led to calls for Bitcoin Core not only to turn off the dust limits, but to disable all standardness rules. In response to this, Bitcoin developer @theinstagibbs wrote an excellent piece explaining all the potential justifications for standardness rules and a list of the standardness rules. Whether markets and mining economics eventually dictate that Bitcoin Core needs to work to try and phase out many of these standardness rules over the long term, or not, is a topic for another day.
Conclusion
In general, it probably is reasonably safe to route small value payments most of the time. HTLCs provide lower protection when the fee rate increases, however HTLCs may still provide some limited benefits even when they appear somewhat uneconomical. Determining exactly when the payment value is too low to be secured by the HTLC is complex and depends on the unique circumstances of the channels involved. In our view, this problem is largely theoretical anyway, compared to the problem of hostile entities just initiating expensive non-cooperative channel closures when fees are high. This wider griefing issue is larger in magnitude, than the problem of routing payments too small to secure.