[Lightning] Eltoo - Convince me that it is safe enough!

[d5000]

Many Lightning supporters seem to have high hopes on Eltoo. Eltoo is basically a new way how the channels in Lightning could be updated. There is a description on the Blockstream website. It would make things like channel factories (Lightning channels for more than two people, which would improve scaling even more) much easier. Eltoo is currently not possible because it needs a softfork on Bitcoin to work (Sighash_Anyprevout).

I haven't found any thread about eltoo in this forum, and I have a doubt I haven't received a convincing answer so far.

Basically, one of the changes which Eltoo proposes is to eliminate the "punishment" for nodes which behave in an uncooperative way. When you close a channel in standard Lightning ("LN-Penalty") because the other party has broadcast an old state of the channel, you can claim the entirety of the channel balance for you. This is an important incentive to avoid misbehaviour in LN.

In Eltoo, in contrast, you can also close channels, but in this case the last "commonly agreed" state of the channel is broadcast. This means that there is no punishment at all.

My doubt is now principally that this could lead to an incentive problem: it would give all scammers the incentive to open LN channels and "simply try" to close channels with old states, as there is no punishment they would only lose transaction fees.

In the Eltoo whitepaper they acknowledge this problem; they propose a mechanism based on an additional security deposit, but this would make the whole system more inefficient as -- from my level of understanding -- for the same level of "punishment" one would have to lock two times the amount in the Lightning channel than with LN-penalty. For example, if I have an 0.01 BTC LN channel, I need to lock 0.01 more to ensure that in the worst case (I'm losing ~0,01 BTC because of the other party closing the channel in a wrong state) the punishment is at least as high as the profit the scammer could get.

So my question is: Is my description of the problem right or am I missing something? Are there ideas or even finished mechanisms to avoid this incentive problem, and which is the "incentive model" of these ideas? I would really like to embrace Eltoo, but I still have doubts about its safety on a massive scale, above all regarding flooding attacks.

Thanks in advance for all serious answers

(Self-moderation note: I know where this discussion could lead, so I will delete any posts which question LN in its entirety because it's off topic here. Eltoo criticism is allowed, but I am, as I wrote, more interested in the "other side".)

[Carlton Banks]

My doubt is now principally that this could lead to an incentive problem: it would give all scammers the incentive to open LN channels and "simply try" to close channels with old states, as there is no punishment they would only lose transaction fees.

each state/update PTLC has a update sequence number, using any old states to channel-close are rejected by validating nodes if a close tx with a newer state has already been confirmed in a block. Because the sequence number is lower for the older state. Higher state numbers override lower state numbers.

Conversely, if a scammer tries to initiate a channel-close with an old state, it's perfectly valid on-chain to override that with another tx that redistributes funds according to the newest state, because the sequence number of newer states are higher.

The scammer spends their own anchor outputs as fees to close with an old state in the latter case, a small but real disincentive to try.

Maybe there are real attacks, perhaps with very busy channels the sequence number might be susceptible to overflow? Didn't check the specifics (and I don't think any actual code exists yet anyway). The old-state attack would work if you get cut-off from all internet past the timeout, but that's no different than with HTLC lightning.

[NotATether]

According to my understanding, I don't think the Eltoo spec allows for broadcasting intermediate state anyway because the proposed SIGHASH_NOINPUT flag would (in their words) "bind a transaction input to any output with a matching script" which eliminates the need to broadcast the intermediate transactions.

Or maybe they still are broadcasted but it says they can't be confirmed because a transaction with a newer state (and thus sequence number) was already broadcasted (?). But I like the idea of not broadcasting any intermediate transactions in the first place, instead only doing so for non-cooperation. So they all get broadcasted sequentially. I have the feeling that this is what Eltoo does too.

[d5000]

each state/update PTLC has a update sequence number, using any old states to channel-close are rejected by validating nodes if a close tx with a newer state has already been confirmed in a block. Because the sequence number is lower for the older state. Higher state numbers override lower state numbers.

Conversely, if a scammer tries to initiate a channel-close with an old state, it's perfectly valid on-chain to override that with another tx that redistributes funds according to the newest state, because the sequence number of newer states are higher.

Thanks. I understand however that if the scammer manages to confirm his "old-state closing" transaction on-chain and the victim doesn't close the channel before the timeout, either because the victim is offline or because the blocks are full and they didn't get space for their own channel update, then the attack could be performed. Or am I understanding something wrong?

The old-state attack would work if you get cut-off from all internet past the timeout, but that's no different than with HTLC lightning.

The difference however is that in HTLC lightning if the victim closes successfully, the scammer gets punished, in eltoo he only loses transaction fees. This is the incentive problem I mean, the scammer can even try flooding blocks with transactions himself to prevent the victims from closing successfully.

One dis-incentive I can imagine is that in the case of the attack being successful, and e.g. there are 3000 from 10000 closing transactions from victims which didn't make it into the blocks before the timeout, it is likely that these 3000 will be those with the least profit for the scammer, because victims with a high level of damage would be willing to pay higher transaction fees. This would be valid both for HTLC-Lightning and Eltoo. But is this enough?

[garlonicon]

Thanks. I understand however that if the scammer manages to confirm his "old-state closing" transaction on-chain and the victim doesn't close the channel before the timeod, either because the victim is offline or because the blocks are full and they didn't get space for their own channel update, then the attack could be performed. Or am I understanding something wrong?

You get it right, but it is the same situation as closing LN channel with old transaction state today. If you can reach one confirmation for some old channel state in LN today, you can steal money from people. That attack can be used in LN and in Eltoo. The same is for dust amounts: they are passed as transaction fees and if something goes wrong, then the miner can collect that coins, because no additional output is created for them.

In LN, that problem is solved by creating a penalty transaction that takes all coins from the cheating party. In LN you need one penalty transaction for each old channel state. In Eltoo you will need only one transaction that can be used as a penalty for any previous N transactions, up to some sequence number or something like that, in this way you can discard previous penalty transactions and store only the latest one.

This is the incentive problem I mean, the scammer can even try flooding blocks with transactions himself to prevent the victims from closing successfully.

I guess that if you flood blocks with transactions, then you have to constuct that transactions somehow. And for that, you have to for example move coins inside Eltoo, paying some second layer fees for each transaction. So I guess that if nodes will be cheated by flooding, then fees will rise, maybe first-layer fees or second-layer fees. Now you can lose all of your coins as a punishment, I expect that if second layers like Eltoo will grow, then that will be reduced to half of your coins, fee-based fraction of your coins or something similar to make attacking unprofitable.

But is this enough?

Yes, I think fees will solve that issue, because fees are needed as an incentive and as a protection from flooding. The more flooding will be there, the more fees will be added to each transaction by nodes. So, if some nodes will be scammed by that kind of attack, then I expect that node operators will rise their routing fees, making that attacks less profitable. I can imagine a system where there is no constant fee rate, but where it depends on how well your node behaves and how many transactions you make.

For example: in Phoenix wallet you have some fees set at 0.1%. That means for each 0.01 BTC (one million satoshi) you have to pay one thousand satoshi in fees. So, when you move 1 BTC, it means you have to pay 100k satoshis in fees. On the other hand, you could transfer that amount on-chain and pay for example 500 satoshi when mempool is almost empty, no matter how big that amount will be. So, I guess that different layers will be used for different purposes, you won't have one layer fitting all use cases. The same with LN and Eltoo, I expect some people will prefer taking all coins as a punishment, some people will prefer taking only the smallest allowed fraction of coins as a punishment, and the free market will set that point somewhere in between.

[d5000]

You get it right, but it is the same situation as closing LN channel with old transaction state today. If you can reach one confirmation for some old channel state in LN today, you can steal money from people. That attack can be used in LN and in Eltoo.

Thanks! OK so far I have got it right, but now to the interesting part:

In LN, that problem is solved by creating a penalty transaction that takes all coins from the cheating party. In LN you need one penalty transaction for each old channel state. In Eltoo you will need only one transaction that can be used as a penalty for any previous N transactions, up to some sequence number or something like that, in this way you can discard previous penalty transactions and store only the latest one.

Is it possible that this penalty transaction, in Eltoo, uses funds which are locked in the LN channel? I had understood in the Eltoo description that the way a penalty could be enforced would be with additional funds (see the last part of my OP). If it would be possible to use the same funds locked in the multisig contract for a penalty (via Sighash_Anyprevout maybe?), like in the current LN protocol (Poon-Dryja channels) then this would be the definitive answer I'm waiting for in this thread Unfortunately my knowledge about Sighash_Anyprevout/Noinput isn't that deep ...

If someone knows some additional links about eltoo/penalty mechanisms, I would be grateful for them to be posted here  (it's not so easy to find material about these topics with search engines)

Edit: Just found this proposal on the Lightning-devel mailing list, I'll see if I'll be able to understand it

I guess that if you flood blocks with transactions, then you have to constuct that transactions somehow. And for that, you have to for example move coins inside Eltoo, paying some second layer fees for each transaction.

I don't understand exactly what you mean ... In my last post I meant "flooding" the blocks with "normal" spam transactions between the wallets of the attacker, to ensure that there is a low amount of space left for closing transactions. (Maybe "flooding" isn't the correct term).

So I guess that if nodes will be cheated by flooding, then fees will rise, maybe first-layer fees or second-layer fees.

Yes, the attacker obviously would have to ensure that his attack still is profitable even with high fees. So he would only generate additional spam/flood transactions in the blocks if the fee level is still too low (or the blocks not full enough) and a too high percentage of the closing transactions are successful.

[garlonicon]

I don't understand exactly what you mean ... In my last post I meant "flooding" the blocks with "normal" spam transactions between the wallets of the attacker, to ensure that there is a low amount of space left for closing transactions. (Maybe "flooding" isn't the correct term).

Oh, I thought you assume that there are two parties involved: the honest node and the attacker. But if there are two nodes controlled by the attacker, then in Eltoo only the latest transaction will remain in the mempool, all previous transactions with lower sequence numbers will be discarded.

Because sequence numbers are 32-bit numbers, that can be abused to exhaust nodes from bandwidth, but I guess that you will have to pay more on-chain fees for replacements. Currently, RBF is designed in a way that every replacement transaction has to cover the cost of itself and the cost of the replaced transaction. As long as you broadcast a single transaction, you have no reason to worry. But if you broadcast hundreds of such transactions, then you will pay for each of your replacement, while other people sending single transaction won't have to.

Is it possible that this penalty transaction, in Eltoo, uses funds which are locked in the LN channel?

As long as the closing transaction is on the mempool level, there is no need for any penalty transaction, you can just broadcast the latest channel state and it will be confirmed instead, because of higher sequence number. However, if some old transaction will reach at least one confirmation, then you need to take that coins somehow. Uncooperative close in LN is protected by CLTV, then you can get attacker's coins directly without any timeout, the same can be used in Eltoo. But I can also imagine a system where you will have that coins locked in some lightning channel instead.

Unfortunately my knowledge about Sighash_Anyprevout/Noinput isn't that deep ...

The concept is quite simple: SIGHASH_ANYPREVOUT means you can use any previous transaction input you want, because that part of the transaction is not signed. That means you can create some closing channel transaction and it will be valid all the time. But that's too much flexibility, because you want to limit it somehow to allow invalidating that transaction later. To do that, you can for example use decreased timelocks, but it seems there is something designed just for that: sequence numbers. If there will be mempool rules discarding lower sequence numbers, you can start from zero, increment it, and transaction with the highest sequence number will be confirmed.

[Carlton Banks]

The old-state attack would work if you get cut-off from all internet past the timeout, but that's no different than with HTLC lightning.

The difference however is that in HTLC lightning if the victim closes successfully, the scammer gets punished, in eltoo he only loses transaction fees. This is the incentive problem I mean, the scammer can even try flooding blocks with transactions himself to prevent the victims from closing successfully.

One dis-incentive I can imagine is that in the case of the attack being successful, and e.g. there are 3000 from 10000 closing transactions from victims which didn't make it into the blocks before the timeout, it is likely that these 3000 will be those with the least profit for the scammer, because victims with a high level of damage would be willing to pay higher transaction fees. This would be valid both for HTLC-Lightning and Eltoo. But is this enough?

I think we might be forgetting why the penalty exists in Poon-Dryja lightning in the first place


If penalty did not exist in the current lightning protocol, a simple griefing attack would be:

• 1. Alice and Mallory have a channel
• 2. Mallory closes with an old state
• 3. Alice closes with newest state to ovverride
• 4. Malloy closes with the exact same old state
• 5. Repeat until no-one is willing to spend yet more money in onchain fees

eltoo's sequence numbers make the above attack impossible. The penalty branch in the Poon-Dryja lightning protocol was the only way to stop that attack, I don't think it's meant as a way of stopping the "Mallory closed with an old state and DDOSed my connection all over the world until her old-state channel-close reached timeout" attack, which is what you seem to be thinking

(correct me if I'm wrong)

[fresheneesz]

> Malloy closes with the exact same old state

Malloy can't close with the same state transaction twice - you can't double spend. There is a clear sequence of transactions. Each presigned uncooperative channel-close transaction is invalidated by making it possible to spend all outputs of that transaction by the counterparty. There is no back and forth possibility in curent lightning unless I have horribly misunderstood something.

I also share d5000's concerns about incentives. Currently, the cost a cheater incurs are:

A. Sending the out-of-date uncooperative channel-close transaction spends fees (presumably half of which came from the cheater, and the other half from their counterparty)

B. When the counterparty claws back the outputs, the cheater loses all their funds. This also covers the cost incurred by the counterparty in step A as a result of that transaction spending some of the counterparty's funds as fee.

With Eltoo, it looks more like:

A. Same as before.

B. Sending a newer state transaction again spends fees from both parties.

Is this corect? If so, it means that the cheater does incur a cost, but its the same cost as the cheater causes the victim to incur. So in this case, a griefer who is willing to lose as much as their victim could grief at 1 to 1 cost. This seems less than ideal.

[d5000]

I don't understand exactly what you mean ... In my last post I meant "flooding" the blocks with "normal" spam transactions between the wallets of the attacker, to ensure that there is a low amount of space left for closing transactions. (Maybe "flooding" isn't the correct term).

Oh, I thought you assume that there are two parties involved: the honest node and the attacker. But if there are two nodes controlled by the attacker, then in Eltoo only the latest transaction will remain in the mempool, all previous transactions with lower sequence numbers will be discarded.

Yes, I understand, but I meant actually another thing: if blocks are e.g. 98% full with non-LN-transactions above the threshold for a "acceptable" fee level (e.g. if the "acceptable" fee for a Lightning closing transactions is considered 100 sat/byte and 98% pay more), and the attacker tries to drive this value closer to 100% with some own transactions, so from the victims' closing transactions only few will succeed. I see however that the longer I think it, the more I think this strategy is very difficult to become profitable due to the high fee payments required for the attacker. It may be possible however in a cartel setting collaborating with a big miner group (which is not required to have 51%, but let's say 10% of the hashrate) which would mine the spam transactions for low fees.

Is it possible that this penalty transaction, in Eltoo, uses funds which are locked in the LN channel?

As long as the closing transaction is on the mempool level, there is no need for any penalty transaction, you can just broadcast the latest channel state and it will be confirmed instead, because of higher sequence number. However, if some old transaction will reach at least one confirmation, then you need to take that coins somehow. Uncooperative close in LN is protected by CLTV, then you can get attacker's coins directly without any timeout, the same can be used in Eltoo. But I can also imagine a system where you will have that coins locked in some lightning channel instead.

Thanks, will need to investigate a bit more here. I'm definitively interested in the case where the victim isn't able to close the channel within the CLTV timeout, due to full blocks/extremely high fees, DDoS, or other causes.

• 1. Alice and Mallory have a channel
• 2. Mallory closes with an old state
• 3. Alice closes with newest state to ovverride
• 4. Malloy closes with the exact same old state
• 5. Repeat until no-one is willing to spend yet more money in onchain fees

Like @fresheneez also remarked, I don't understand how the steps from 3 on could work if transaction 2 is already confirmed on-chain (it's different if they're "battling" for inclusion in a block while both are in the mempool still, but in this case they won't spend fees until one is confirmed). In LN-Penalty at least, i.e. without Sighash_Anyprevout, afaik in all states you have only one output you could spend to settle the LN channel state on chain, so once confirmed all other transactions should be invalid, or not?

I don't think it's meant as a way of stopping the "Mallory closed with an old state and DDOSed my connection all over the world until her old-state channel-close reached timeout" attack, which is what you seem to be thinking

The scenario I have in mind is the following: Many LN users will not be 24/7 online, but let's say a few hours per day, to be able to react to any malicious channel close. The attacker could speculate that at least a certain percentage of this "retail LN user group" could not use watchtowers or similar mechanisms, and thus wait for a moment in the week where the transaction fee level is relatively high (often Wednesday/Thursday) and close channels massively just before the predicted start of the "high fee cycle" in the early morning in Europe, which is often the moment with the lowest fees.

With the attacker's channel closing transactions taking away most of the "low fee slots", fees would increase fastly, and the victims from the attack closing their channels would drive them even higher. So the attacker can speculate that some victims, above all those mentioned above that are not online 24/7, will not be able to close their channel in time.

In LN-penalty, this attack would be probably impossible as the attacker always has to calculate his possible profit taking into account the penalty amounts he could lose. In Eltoo, instead, he only has to calculate with transaction fees as costs. So my fear is that the attack could become so cheap that some would simply try it, above all if they could collaborate with miners, and eventually succeed.

[ndalliard]

I don't think it's meant as a way of stopping the "Mallory closed with an old state and DDOSed my connection all over the world until her old-state channel-close reached timeout" attack, which is what you seem to be thinking

The scenario I have in mind is the following: Many LN users will not be 24/7 online, but let's say a few hours per day, to be able to react to any malicious channel close. The attacker could speculate that at least a certain percentage of this "retail LN user group" could not use watchtowers or similar mechanisms, and thus wait for a moment in the week where the transaction fee level is relatively high (often Wednesday/Thursday) and close channels massively just before the predicted start of the "high fee cycle" in the early morning in Europe, which is often the moment with the lowest fees.

all the lightning stuff is pretty new to me, please excuse me if what i am about to say is wrong - learning daily. i stumbled upon the watchtime-blocks setting in c-lightning here. setting this to the maximum of 2016 would mean, that users who are not 24/7 online, would need to be online once every two weeks, to check for a malicious channel close. which would make your proposed attack scenario more unlikely or harder to execute. this is possible now and should be possible with eltoo enabled, if i understand the setting correctly and what it is supposed to do. as i said - correct me if i am wrong here. nice discussion btw.

[garlonicon]

The scenario I have in mind is the following: Many LN users will not be 24/7 online, but let's say a few hours per day, to be able to react to any malicious channel close. The attacker could speculate that at least a certain percentage of this "retail LN user group" could not use watchtowers or similar mechanisms, and thus wait for a moment in the week where the transaction fee level is relatively high (often Wednesday/Thursday) and close channels massively just before the predicted start of the "high fee cycle" in the early morning in Europe, which is often the moment with the lowest fees.

If that attack will be repeated too many times, then I expect that timelocks will be increased. For example, you could have one or two week timelock in case of uncooperative close, and then you can wait more time, and pay lower fees.

setting this to the maximum of 2016 would mean, that users who are not 24/7 online, would need to be online once every two weeks, to check for a malicious channel close. which would make your proposed attack scenario more unlikely or harder to execute

Exactly, currently two weeks is the maximum, because by default after that time transactions are removed from mempool.

With the attacker's channel closing transactions taking away most of the "low fee slots", fees would increase fastly, and the victims from the attack closing their channels would drive them even higher. So the attacker can speculate that some victims, above all those mentioned above that are not online 24/7, will not be able to close their channel in time.

Again, the timelock depends on how long you can be online. If you are offline for a long time and if you don't want to use any watchtower, you should increase your timelock (or create two unidirectional channels to make publishing the old state unproftitable). Also, each victim using Eltoo will replace the attacker's closing channel transaction, so the cost of stopping that attack is roughly the same as the cost of starting it, when it comes to the space (I don't know how it will be treated when it comes to the fees, but I expect similar approach as in RBF).

In LN-penalty, this attack would be probably impossible as the attacker always has to calculate his possible profit taking into account the penalty amounts he could lose. In Eltoo, instead, he only has to calculate with transaction fees as costs.

It is true only if we are on mempool level. I think in case of reaching one confirmation, there should be some way for Eltoo users to take that coins in case of uncooperative close, when it will turn out that the state published on-chain is not the latest one. In LN, CLTV's are used, I think in Eltoo the same way could be implemented.

[Rath_]

The scenario I have in mind is the following: Many LN users will not be 24/7 online, but let's say a few hours per day, to be able to react to any malicious channel close. The attacker could speculate that at least a certain percentage of this "retail LN user group" could not use watchtowers or similar mechanisms, and thus wait for a moment in the week where the transaction fee level is relatively high (often Wednesday/Thursday) and close channels massively just before the predicted start of the "high fee cycle" in the early morning in Europe, which is often the moment with the lowest fees.

Exactly, currently two weeks is the maximum, because by default after that time transactions are removed from mempool.

Why would that matter in LN-penalty anyway? A commitment transaction can be confirmed as soon as it's broadcast. The hash of the locking script which contains that timelock is included in one of its outputs. The penalty transaction spends that output and since it's not a pre-signed transaction, the user should be able to set a high fee matching the current state of the mempool. If the commitment transaction sits unconfirmed in the mempool then there is no risk for the victim because of the CSV timelock. If either the commitment or the penalty transaction is dropped from the mempool then they can be rebroadcast. Am I missing something?

I can see how a DDoS could stop someone from detecting the fraud and broadcasting the penalty transaction, but the attacker has no way of telling if the victim is running a watchtower. Also, if someone is running their node only behind the Tor, doesn't it make them invulnerable to this?

Once the timelock has expired, both the attacker and the victim can spend that output. The attacker would also need to pay an extremely high transaction fee. 

By the way, the Lightning Network paper describes how a timestop could be used to mitigate this attack.

[Carlton Banks]

Like @fresheneez also remarked, I don't understand how the steps from 3 on could work if transaction 2 is already confirmed on-chain

they're all state-update transactions, and they're all valid on-chain. That's the whole point, it wouldn't work otherwise.

In LN-Penalty at least, i.e. without Sighash_Anyprevout, afaik in all states you have only one output you could spend to settle the LN channel state on chain, so once confirmed all other transactions should be invalid, or not?

not.

If all other updates are invalid once one of them is confirmed on chain, again, the protocol wouldn't work. You're describing the most naive prototype of payment channels possible, that's not what the protocol is at all.


Put simply:

1. Current Lightning (penalty) permits any updates in any order, on-chain
2. Eltoo Lightning (no-penalty branch) permits updates only in the agreed order, on-chain

You would waste alot in fees if you put all the update txs onchain (and it would be orders of magnitude slower), but the whole point of Lightning is that it would be entirely valid to do so.

[fresheneesz]

@Carlton
> they're all state-update transactions, and they're all valid on-chain. That's the whole point, it wouldn't work otherwise.

All the state update transactions are valid on-chain, yes that's true. *Until* any one of them is confirmed on chain. Then none are valid. However, the refund (anti-cheating) transaction becomes valid if the confirmed transaction is an out of date state. Once the refund transaction goes through, there are no more presigned transactions that are valid - both parties have their final money from the channel and its fully closed.

> permits any updates in any order, on-chain

I don't believe that's true. You can't spend the same output twice, and all these are pre-signed transctions. What mechanism do you think is being used to allow these update transactions to be spent in "any order"? I don't think such a mechanism exists. What am I missing Carlton?

[d5000]

If that attack will be repeated too many times, then I expect that timelocks will be increased. For example, you could have one or two week timelock in case of uncooperative close, and then you can wait more time, and pay lower fees.

Two weeks may be enough in many cases, but not in all. As far as I know most Lightning software has a default of 1 week of less for to_self_delay (correct me if this is wrong), which can be already dangerous in situations where the blockchain is relatively full (e.g. periods of high volatility).

Also, each victim using Eltoo will replace the attacker's closing channel transaction, so the cost of stopping that attack is roughly the same as the cost of starting it, when it comes to the space (I don't know how it will be treated when it comes to the fees, but I expect similar approach as in RBF).

The fee could be a problem if the attacker carefully plans his attack, analyzing high/low fee times and planning it so that the attack itself is still in low-fee time, but the default timeout will be in a high-fee time. The channel closing transactions in the case of an attack are additional transactions to the average "dust of transactions", so it's likely the fees will rise sharply above the average.

Where I see the problem is a constellation like the following:
- Let's think the attacker has succeeded to close channels for a fee of 1000 sat on average (0.00001 BTC), for example on a Sunday night, and most timeouts are in a week.
- The average "gross" value of the theft (=the damage done to the victims, i.e. the difference between the old state and the current state) is 20000 sat (0.0002 BTC) per channel.
- The attacker now calculates that 80% of the victims' channel closings will succeed. This means that he has to multiply x5 his attack cost per successful theft (he has to close 5 transactions for 5000 sat to achieve one theft of 20000 sat). This means his profit is 15000 per successful theft/channel.
- Now the victims start to close channels, a panic emerges and minimum tx fees for inclusion in a block climb x20. This increase can even happen without any attack, although normally in the "weekly fee curve" we see more something close to x10. But in the case of an attack, even x50-x100 is not impossible at all, although it may lower at the weekend.
- This means that the transaction fees for the victims' channel close transactions are now on average 20000 sat, which is (in most cases) as high as the damage for them. From those victims that are "late to the party", i.e. closing near the timeout, many will refrain to close the channel and simply take the loss. In these cases, the attacker has succeeded, he is likely to achieve the 80% "goal" which he has planned with.

In all cases where the attacker's calculation of his "success rate" (in this case, that only 80% of victims close their channel successfully) is not completely off (i.e. lower than 95% successful victim channel closures), he makes a profit.

Once the timelock has expired, both the attacker and the victim can spend that output. The attacker would also need to pay an extremely high transaction fee.

Yes, the transaction fees for the attacker would also be high when he wants to move the coins after the timeout. This would favour the victims, but they would have to monitor fees closely and close as fast as possible once fees are reasonable, and maybe the attacker can speculate that some would wait too long (hoping for a further fee decrease to try to recover funds).

Without a penalty, the incentive model in these kinds of attacks could tend to favour the attacker, at least in specific constellations of fee evolution (which are not uncommon), and thus give incentives to simply try massive attacks in low-fee phases where a fee increase is likely, hoping for a fee increase.

By the way, the Lightning Network paper describes how a timestop could be used to mitigate this attack.

Thanks, I didn't remember this part of the paper. I re-read the main part in the last days, that's also one of the reasons why I'm slow in answering

However, these timestops could introduce new vulnerabilities (I can imagine, for example, a bribing attack of a short seller to a miner to not include the "timestop flag" into a congested block, which could be interpreted by the Bitcoin community as a "failure of the system" and lead to a crash, letting the short seller succeed). I could, however, imagine to build upon this proposal, so I'll try to investigate.

For example, to not depend on miners, one could in theory add a special kind of sequence numbers which increase only if the fee level of the lowest decile of all transactions in a block is lower than a specific threshold viewed as "acceptable" by the contract programmer. This would however need additions to the protocol and could also lead to more complicated/resource-consuming validation work for full nodes.

@Carlton Banks: I'm referring to the variant of Poon-Dryja channels described in the Lightning whitepaper. I just re-read it and it seems to confirm the position that once a commitment transaction is confirmed on-chain, no further commitment transactions can be confirmed because the output of the funding transaction is spent. If "modern LN-Penalty" is working differently I would be grateful for a link to an explanation.

[Karartma1]

Hey OP, great thread  
I suggest you have a look at the following page on Bitcoin Optech which provides quite some relevant material and documentation on eltoo. I share some of your questions but I've no answers and I'll be following this thread very closely.
https://bitcoinops.org/en/topics/eltoo/

[Carlton Banks]

@Carlton Banks: I'm referring to the variant of Poon-Dryja channels described in the Lightning whitepaper. I just re-read it and it seems to confirm the position that once a commitment transaction is confirmed on-chain, no further commitment transactions can be confirmed because the output of the funding transaction is spent. If "modern LN-Penalty" is working differently I would be grateful for a link to an explanation.

I am not referring to the real protocol, I was trying to show what would happen if we take the penalty mechanism away from Poon-Dryja. But you're not really listening

Your point is still wrong regardless:

• if a cheating channel-close happens in Poon-Dryja (i.e. today's) lightning, and the timeout unlocks, the penalty transaction will not work
• if a cheating channel-close happens in Eltoo lightning, and the timeout unlocks, the corrective transaction will not work

Eltoo has the problem, and so does regular Lightning.


maybe close your thread?

[d5000]

I am not referring to the real protocol, I was trying to show what would happen if we take the penalty mechanism away from Poon-Dryja.

Still, once the commitment transaction has been confirmed, no other commitment transaction could be confirmed. In the case ("LN-Penalty without penalty") you described, Mallory would be able to steal the money (=difference between old state and current state) and Alice can't do anything to prevent that. Of course, this attack makes Poon-Dryja without penalty impossible, or it would need another security mechanism.

But that's not my point, the point is that generally Poon-Dryja with penalty favours, incentive-wise, the victims. Eltoo instead has an "equilibrium", as in an incooperative close nobody loses (besides tx fees). It makes certain attacks impossible, but in other cases, this equilibrium could favour attackers in certain constellations of fee level/evolution, block congestion, and the percentage of honest/dishonest/opportunistic LN nodes and the connections between them.

Your point is still wrong regardless:

• if a cheating channel-close happens in Poon-Dryja (i.e. today's) lightning, and the timeout unlocks, the penalty transaction will not work
• if a cheating channel-close happens in Eltoo lightning, and the timeout unlocks, the corrective transaction will not work

This is all true, but how is that related to the incentive problem I mention above? I fear there is a misunderstanding between us

@Karartma1: Thanks, I know this page already, it's a really good source of information.

For now, my conclusion is:

- The fee market could make Eltoo work, as written in the last post. In the attack case I described, a race would emerge between the attacker and the victims after the timeouts, probably in high-fee times, and the attacker is likely to lose, or at least it would be difficult to reach his goal of a certain profit percentage because of the high fees. The problem I see here is the following: If the victim sees it's being attacked (because an older commitment/update transaction was confirmed) but the money not taken, they could be fooled to think they should wait until fees lower (so they can recover the money), and this gives again an upside to the attacker.
- Timestops or derived solutions could be definitively interesting, but the problem with attacks on that system (e.g. by short-sellers) remains.

(Edit) Two more critical situations come into my mind:
- In low-fee phases (e.g. around widespread holidays like Christmas) it could be attractive for attackers to simply try out closing channels with old states to speculate on a small number of victims having forgot about their channels, if the fee level is low enough then their expected attack profit (if e.g 1 of 1000 victims forgot about their channel and don't close in time) could exceed their cost for both the state-update tx and the following "theft" transaction.
- The combination of a massive channel-closing attack like described above with short-selling Bitcoin, to profit from a generalized panic. In this case the attacker may make most profit from the short and not from the LN attack per se.

So I'm still grateful for any input and won't close the thread ... I hope also to be able to read about Eltoo-penalty these days.

[Carlton Banks]

Your point is still wrong regardless:

• if a cheating channel-close happens in Poon-Dryja (i.e. today's) lightning, and the timeout unlocks, the penalty transaction will not work
• if a cheating channel-close happens in Eltoo lightning, and the timeout unlocks, the corrective transaction will not work

This is all true, but how is that related to the incentive problem I mention above? I fear there is a misunderstanding between us

your point is: "what if the attacker somehow DOS'es the victim, and the channel-close reaches timeout"

and timeout means game-over anyway. So you've "discovered" an attack that's exactly the same for Eltoo and Poon_Dryja