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.

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

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

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

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)

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.

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.

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.

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

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.


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.

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?

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