[ad_1]
Summary: When making low worth funds on the lightning community, particularly in “excessive” onchain price environments, the safety advantages of the lightning’s HTLC system could also be considerably restricted. This downside might solely be relevant in a restricted variety of situations, particularly whereas the fee is in-flight and primarily for fee routers. Quantifying the magnitude of this downside will be fairly sophisticated, because it is determined by the specifics of the channels concerned. Nevertheless, whereas fascinating in principle, the difficulty is probably not as vital because the extra easy downside of channel counterparties griefing one another with costly non-cooperative channel closures, no matter any low worth in-flight funds.
![](https://blog.bitmex.com/wp-content/uploads/2021/01/05-BitMEX-Research-Twitter-1024x572.png)
The Downside With Low Worth Lightning Funds
Just lately, on Twitter, some have urged that lightning funds may not be trustless for small quantities. It’s because in-flight funds are protected by Hashed Timelock Contracts (HTLCs) and if the HTLC prices extra onchain when used, than the worth being protected, maybe the lightning community is not trustless. This challenge doesn’t solely happen if the HTLC prices extra in onchain charges than worth being protected, however even when the onchain charges are vital. As an illustration, a person shedding half their cash in charges to guard a fee can also be sad. This challenge will be known as the uneconomical HTLC downside.
This challenge could also be of concern, as a result of low worth funds have been speculated to be one of many core use circumstances for lightning. Certainly, lightning is alleged to be unsuitable for giant worth funds as a result of it could be too tough to search out the liquidity. In an atmosphere with “excessive” prevailing Bitcoin transaction charges, say of 30,000 sats for a typical transaction, this might imply one can’t securely spend lower than 30,000 sats utilizing lightning, which could possibly be a significant weak point. This might imply lightning is simply helpful for “medium” worth funds.
Some Tweets articulating this downside can be found under:
When The Downside Applies
The primary option to strategy this downside is attempting to ascertain precisely when this downside applies. The issue solely happens when funds are in-flight. As soon as a lightning fee has been settled and the dedication transactions have been up to date, the funds are safe and HTLCs usually are not required. Even funds as little as 1 sat will be considered safe, so long as they’re settled. A multi-hop fee can also be crucial, for the reason that safety advantages of HTLCs solely apply to multi-hop funds. HTLCs are nonetheless technically used for single hop funds, to maintain the fee stream system as related as potential and cut back complexity, however HTLCs solely present added safety within the occasion of a multi-hop fee. This uneconomical HTLC challenge due to this fact solely actually applies to the fee router. The sender is attempting to spend funds, so doesn’t depend on the HTLC for defense. Likewise the ultimate recipient both receives the fee or they don’t. And naturally, even when the issue of uneconomical HTLCs arises, the fee will nonetheless work simply advantageous more often than not. It’s simply that the router is liable to being griefed, if the opposite events try to troll them and waste their sources. The attacker doesn’t profit from this themselves, so there is no such thing as a main incentive downside, it’s simply a possibility to troll over customers of the community.
Please see under a diagram of a 4,000 sat fee from Alice to Charlie, routed through Bob. If the prevailing market price price is “excessive”, as an illustration 50 sats/vB, if Alice goes offline whereas the fee is in-flight, the HTLC defending Bob could also be uneconomical to make use of. As an illustration, redeeming the HTLC output might devour round 100 digital bytes of blockspace, at 50 sats/vB, that’s 5,000 sats. This compares to the output worth which is simply 4,000 sats. Due to this fact, Bob would lose 1,000 sats if he might sweep up the UTXO. In actuality after all, Bob might not sweep up the UTXO and the output may sit there indefinitely. It’s straightforward to see why the HTLC didn’t actually add to Bob’s safety and why routing 4,000 sats is insecure.
The above description of the issue is an oversimplification. The fact of the issue is extra advanced and tough to analyse, and requires some information of HTLCs and lightning channel building. Really, this 5,000 sats redemption price might technically be the fallacious price to contemplate.
Illustration of a profitable lightning transaction with HTLCs
![](https://blog.bitmex.com/wp-content/uploads/2023/05/htlc-1.gif)
Within the above situation, when in-flight funds are insecure, the roles of the three events are as follows:
- Alice is the attacker
- Bob is the sufferer
- Charlie is okay both manner
In a excessive price atmosphere, if the fee fails, Bob is more likely to must pay some huge cash in charges to shut the channel anyway. The additional cash spent on the HTLC goes to be low by comparability. Due to this fact, this assault is basically theoretical and never significantly vital. The principle downside is that top charges could make non-cooperative channel closures costly. This assault will be considered a subset of that wider downside.
Within the instance above, Alice is supposedly making an attempt to pay Charlie 4,000 sats, through Bob. On this assault situation, Alice decides to grief Bob by refusing to finish the HTLC within the remaining step. Bob now has to provoke an costly non-cooperative channel closure transaction in his channel with Alice, with an additional HTLC output of 4,000 sats. Bob has paid Charlie 4,000 sats and if he doesn’t receives a commission by Alice, he loses cash.
Who Pays The Onchain Charges?
To correctly perceive this downside, we now want to contemplate all of the transactions concerned and who pays the onchain charges. The primary transaction is the non-cooperative channel closure. The charges for this transaction are paid for by whoever opened the channel, which could possibly be Alice or Bob. If Alice opened the channel, then the uneconomical HTLC downside doesn’t apply right here, since Bob (the sufferer) isn’t paying the charges related to the HTLC output, and due to this fact the HTLC nonetheless protects him. Alice is due to this fact not more likely to even trouble initiating this assault if she was the one who opened the channel.
If Bob opened the channel and due to this fact pays the charges, it could possibly be crucial to interrupt this price fee down into two parts. There may be the unique a part of the price and an additional a part of the price wanted to pay for the additional HTLC output. In principle, this authentic a part of the price will not be a part of the uneconomical HTLC downside, as a result of it might have needed to be paid anyway, whatever the low worth lightning fee. Alice might have simply performed a pressured channel closure anyway. Nevertheless, when the HTLC was arrange, a brand new dedication transaction was agreed, the place some funds have been deducted from the quantity going again to the occasion who opened the channel, that is with the intention to pay for the additional HTLC output. The HTLC output is round 32 bytes, due to this fact this further price might have been round 3,200 sats (Assuming a prudent 100 sat/vB price price). Due to this fact, if Bob opened the channel, you possibly can argue that there is no such thing as a HTLC safety when routing a fee under 3,200 sats. We argue that that is the core of the uneconomical HTLC downside. In our instance, Bob remains to be a internet beneficiary of the HTLC, for the reason that fee worth was 4,000 sats, due to this fact he makes a “revenue” of 800 sats. Due to this fact the HTLC might present some safety, however Bob will not be more likely to be particularly glad.
Who pays the charges? |
Uneconomical HTLC downside |
|
The unique non-cooperative channel closure onchain price |
The charges for this transaction are paid by whoever initiated the channel opening. This could possibly be Alice or Bob. |
Whereas this transaction has excessive charges and is pricey, since there is no such thing as a further price related to the HTLC, this transaction does not contribute to the uneconomical HTLC downside. The charges right here will be thought-about as sunk prices. |
The additional price within the non-cooperative channel closure for the HTLC output | This price contributes to the uneconomical HTLC downside, it’s an additional price incurred because of the HTLC. Nevertheless, this solely contributes to the issue if the sufferer pays. | |
Redemption of the HTLC output |
The charges are paid for by the “sufferer” of the uneconomical HTLC assault. (i.e. Bob) |
These transaction charges might contribute to the uneconomical HTLC downside, relying on how the issue is analysed. (See the subsequent part) |
Redemption Of HTLC Output
There may be additionally a second transaction concerned on this downside. Bob goes to want to redeem his small HTLC output in some unspecified time in the future sooner or later to consolidate it with the remainder of his funds. There may even be charges related to this transaction and Bob is more likely to make an total loss in our instance. These charges are more likely to be loads bigger than the additional quantity added to the dedication transaction to incorporate the HTLC output, 5,000 sats as calculated above. When these charges are thought-about, in our situation, it might imply Bob will not be protected by the HTLC for lightning funds of as much as 8,200 sats. Nevertheless, whether or not these charges must be included within the uneconomical HTLC downside is much less clear.
One purpose to exclude these redemption prices from the uneconomical HTLC downside is that onchain charges might go down sooner or later. Bob should be in revenue from the HTLC, so long as he’s affected person. He might patiently watch for charges to fall after which consolidate the output. Or perhaps he might discover a good samaritan miner prepared to incorporate his consolidation transaction in a block, for a low price. This miner could possibly be attempting to profit Bitcoin by lowering the dimensions of the UTXO set, miners have produced blocks like this earlier than. Or perhaps in some unspecified time in the future within the far future, Bitcoin will improve the consensus guidelines, with a deal with lowering the UTXO set, turning mud UTXOs into spendable cash. Our level is that even when the HTLC appears uneconomical when the channel closes, this will change sooner or later. Due to this fact the HTLC might present some restricted safety advantages and Bob might get some satisfaction understanding that he has a 4,000 sat UTXO sitting there. It’s higher than nothing.
Uneconomical HTLCs Can Nonetheless Be Useful
In lightning, Bob (or protocol designers) have two decisions for coping with these low worth funds, create this uneconomical to redeem HTLC or don’t have any HTLC in any respect. Simply because the HTLC is uneconomical and leads to losses for Bob, it doesn’t essentially observe that the HTLC is ineffective. Within the above instance, one can argue that Bob’s HTLC might have labored, no less than to some extent, despite the fact that he might have misplaced cash. The uneconomic HTLC should have helped deter attackers.
Contemplate the next instance. What if you’re strolling on the road and a prison approaches you threatening to assault you in the event you don’t hand over your pockets. Your pockets accommodates US$100 in notes. You even have a hidden panic button on you, that alerts an elite personal safety power, which may swoop in by helicopter and prevent. This service prices US$1,000 every time you employ it. Would you press the button? In the event you press the button you continue to have your authentic US$100, however you’re out of pocket US$900, having spent a US$1,000 price for the service. Regardless that you misplaced cash, the safety system can nonetheless work and you may deter future attackers. Your authentic US$100 remains to be protected. After all many won’t agree that this analogy is suitable. The most important weak point being that the profitable road thief might get to maintain the US$100 in money. Within the lightning community assault, the perpetrator (Alice) will get nothing. Due to this fact, as a substitute of a typical thief, think about extra of a sadistic bully kind character, demanding you hand over your pockets to allow them to burn the cash in entrance of you. On this contrived situation, would you continue to press the panic button and pay $1,000? After all, we’re open to the criticism that our analogy right here is considerably silly and inappropriate. In the true world you don’t need to be attacked, whereas on lightning solely cash is at stake, you don’t care the way you lose it or which kind of funds you lose.
There may be no less than one situation when the uneconomical HTLC supplies a extra concrete instance of safety. What if Alice (The attacker) can also be a big miner. If no HTLC output is produced in any respect, this 4,000 sats is added as a price to the miner. That is further marginal earnings, for the reason that transaction measurement of the dedication transaction is unchanged, however the price is greater. There may be due to this fact an assault situation the place a big miner turns into a lightning person, solely to steal HTLCs. The uneconomic HTLCs do assist deter this assault. Then again this assault is unlikely to materialise, as a result of the worth of funds at stake shall be essentially low, in all probability not vital for a big miner.
In our view, in our instance Bob isn’t any worse off by having the HTLC output. The one draw back to Bob is the additional 32 bytes the HTLC output provides to the channel closure transaction, which he solely pays for if he opened the channel. Due to this fact, despite the fact that the uneconomical HTLC downside is actual for low worth funds, from a protocol design perspective it’d nonetheless be price having these HTLCs. The choice, no HLTC in any respect, is even worse.
Bitcoin Core Mud Relay Limits
Above we defined why it’s price retaining HTLCs, even when it’s uneconomical to redeem the output. Nevertheless, what if the worth you’re sending over lightning is so low, for instance 1 sat, that it’s under the Bitcoin mud relay restrict? On this situation, your lightning node won’t even create an HTLC for you. An HTLC output can’t be created, as a result of Bitcoin Core nodes wouldn’t relay the transaction. The transaction with a 1 sat output might nonetheless be legitimate in keeping with Bitcoin’s consensus guidelines, it’s only a non-standard transaction so won’t be relayed.
Bitcoin Core has a transaction relay mud restrict price price of 3 sats/vB. A transaction with a price price under this stage won’t be relayed, due to this spam prevention characteristic. This per transaction restrict will not be essentially an issue for HTLCs, the dedication transaction can have a price price greater than 3 sats/vB, even when there’s a 1 sat output. Bitcoin Core additionally has relay guidelines for the minimal worth of an output, for it to be relayed. A P2WPKH output is round 31 bytes in measurement and can devour round 67 digital bytes to spend, which is 98 digital bytes in whole. Due to this fact the mud restrict for the worth of a P2WPKP output is 294 sats (3 x 98). For a lightning output, this restrict could also be a bit greater, because it’s a 2 of two multisignature spend.
Which means that for in-flight funds under round 500 sats, the router ought to contemplate the fee as trusted. It is a a lot stronger manifestation of the issue as there is no such thing as a HTLC safety in any respect. Prevailing market price charges don’t truly matter right here in any respect both. It doesn’t matter if the market clearing price is 1,000 sats/vB or 5 sats/vB, the mud relay restrict brought about the difficulty. The lightning protocol does enable node operators to specify a minimal HTLC measurement, which will be modfied relying on prevailing market onchain price charges.
Eradicating The Mud Restrict
Some folks have argued for eradicating the mud limits for varied causes. For instance Bitcoin developer Jeremy Rubin itemizing 5 causes to take away the mud restrict under:
- it’s not our enterprise what outputs folks need to create
- mud outputs can be utilized in varied authentication/delegation good contracts
- mud sized htlcs in lightning power channels to function in a semi-trusted mode which has implications (AFAIU) for the regulatory classification of channels in varied jurisdictions; agnostic remedy of fund transfers would simplify this (like getting a 0.01 cent dividend verify within the mail)
- thinly divisible colored coin protocols may make use of sats as worth markers for transactions.
- ought to we ever do confidential transactions we will’t stop it with out compromising privateness / allowed transfers
Supply: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019307.html
Please notice purpose two above. Growing safety for low worth funds in lightning is cited as a purpose to take away the mud restrict altogether. Eradicating the mud restrict might enhance safety for low worth lightning funds. Nevertheless, this safety profit right here is proscribed, no less than when market price charges are above 3 sat/vB, as a result of whereas the low worth HTLCs might now be relayed, the outputs would nonetheless be uneconomical to redeem.
Jeremy’s proposal to take away the mud relay restrict proved unpopular amongst some builders. The argument veered in the direction of the 2014 OP_Return debate and the 2023 Ordinals debate, as as to whether Bitcoin is just for “monetary transactions” or if the system ought to produce other makes use of. This has even led to requires Bitcoin Core not solely to show off the mud limits, however to disable all standardness rules. In response to this, Bitcoin developer @theinstagibbs wrote a wonderful piece explaining all of the potential justifications for standardness guidelines and an inventory of the standardness guidelines. Whether or not markets and mining economics finally dictate that Bitcoin Core must work to try to part out many of those standardness guidelines over the long run, or not, is a subject for one more day.
Conclusion
Normally, it in all probability within reason protected to route small worth funds more often than not. HTLCs present decrease safety when the price price will increase, nonetheless HTLCs should present some restricted advantages even once they seem considerably uneconomical. Figuring out precisely when the fee worth is simply too low to be secured by the HTLC is advanced and is determined by the distinctive circumstances of the channels concerned. In our view, this downside is basically theoretical anyway, in comparison with the issue of hostile entities simply initiating costly non-cooperative channel closures when charges are excessive. This wider griefing challenge is bigger in magnitude, than the issue of routing funds too small to safe.
Associated
[ad_2]