Topic: [Lightning] Eltoo - Convince me that it is safe enough! (Read 581 times)

I've now re-read the Eltoo whitepaper (Source link) to look more closely at the fee issue. It is described in p. 14 ff. I quote:


So both parties have to spend fees. The attacker adds his fees to the old update transaction, while the victim has to add own fees to override the old update with the new one. This means that unfortunately the situation I described is possible, where the victim is damaged by the fees they have to spend, although it also involves a certain punishment for the attacker (which would not occur in Poon-Dryja without penalty, which is not possible in a meaningful way anyway). This may rise the attack cost a bit. It may be enough.

In conclusion (until now), I like Eltoo a bit more now, but I still feel safer combining it with a penalty, or would use Eltoo without penalty only for smaller channels, e.g. a "prepaid card replacement", or to entities I have a certain trust level like described above (friends, established companies etc.).

@ garlonicon
> I think that free market will settle this value somewhere in between

I hope so. Does Eltoo allow for that variable to be chosen by individual channels? I didn't think so. I think that probably the right penalty is to pay the cost of all required on-chain transactions. Eg for Eltoo, this would be the cost of 2 transactions (the cheating transaction and the revoke transaction). It makes sense for the malicious/confused party to pay for the damages. Much more beyond that is excessive, anything less than that isn't fair to the victim.

no, the victim doesn't pay the fees. we agreed earlier on in the thread that the attacker paying the fees of the correct channel close was part of the deterrent in eltoo, it seems you forgot how... fishy

And so if anything, increasing fee environments dissuade an attempted attack; if the victim notices a false close, they could choose any time they like during the timeout's validity to inflict as much fees as possible on the attacker.

Yep, I think if an Eltoo-penalty variant is implemented then you should be right here. I had still no time to read thoroughly through the Eltoo-penalty proposal, but plan to do that soon. Even a relatively small penalty could perhaps already reverse the incentive problem and balance it again in favour of the victims, together with the fee issue (and maybe longer timelocks).

This is a valid argument, yes, above all if the counterparty is able to hack your transaction information. You should be safe once you deleted all old states, but the channel partner can simply be silent about the old transactions he/she was able to steal from you.

Even if Eltoo really is less secure than LN-Penalty, then it could be an interesting option for channels where trust is not totally zero (between friends, to an "established" exchange etc.), or if the node owner can be 100% sure that he 1) can be online [this may require a "plan b" like setting up several devices, and some technical knowledge, so it's not a trivial assumption] and 2) uses a trustable watchtower. However, the incentive problem should always be clarified to users. And penalty-based variants (be it traditional Poon-Dryja or Eltoo-penalty) should also always be possible and support not dropped "because an attack never occured".

@Carlton Banks: Always spicy, like I like it
Not really. The attack itself (speculative uncooperative close) is known, but the incentive/game theory implications maybe are not as thoroughly discussed as they should (correct me if I'm wrong). That's the "minor contribution" I could claim in this thread.

... and is able to confirm a breach remedy transaction in time and for tx fees << damage (which is not the same as "being online"). The attacker has an advantage here, because for him/her every theft which is higher than the fees he used is a profit, while the victim always will suffer damage if it has to close the channel for high fees.

I think not. The penalty is not directed against a specific attack, but in general as a tool against uncooperative closes, thus it is legitimate to discuss all situations where an uncooperative close could be attractive for any malicious user group.

By the way, you're not leaving the best impression in your last contributions to the thread (you started well, it's a shame a bit). Take into account tha the thread starts with "Convince me", and other users may also be waiting for a confirmation that Eltoo is safe, but you're unfortunately giving the impression that you don't want certain things to be discussed.

I think we both want Lightning to succeed, and I would also like to embrace eltoo, but if I get these kind of answers then you'll make me smell something fishy even if there isn't anything.

@fresheneesz: don't worry, I will not close this thread because of some comment, at least while the discussion is somewhat interesting. I only sometimes need a bit more time for posts in the technical section, to have time to read relevant documents and unterstand the issues better.

@Carlton

> maybe close your thread?

That's pretty rude dude. Not cool.

that's why I put quotation marks around the word, you've discovered nothing whilst behaving as if you have



and the outcome is the same, cheating isn't possible while someone (either an honest node or their watchtower) is online


the penalty is not there to solve the problem you think. you're embarrassing yourself

As I said before: you can have 100% coins taken as a penalty or you can have no penalty. I think that free market will settle this value somewhere in between, because for some people it may be unacceptable to have 100% penalty (it may be even expressed in some other way, not necessarily as a percentage of the amount). Also because that penalty is one of the reasons why I don't want to put all of my coins into Lightning Network: because if something goes wrong, then all my coins might be taken by another node. But if more and more users will transact without touching on-chain coins or only touching them once per week, month, year, and maybe even less often in the future, then there should be some way to encourage people to store their coins in LN in a way where they don't have to put all of their coins at risk.

It's not necessarily a DOS, it can also be simply speculation on inactivity (by the way, I didn't "discover" any attack, they're mostly known for a long time).

But anyway, you're completely right ... a successful old-channel-close attack has the same consequences in Eltoo and Poon-Dryja. But that's what is exactly worrying for me, because the incentive model is different, due to the attack cost being always higher in Poon-Dryja due to the penalty.

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

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.

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.

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?

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/

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).


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.

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.

@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?

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


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.

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.

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.

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

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).

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.

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.

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.

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.


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?

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.

> 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.