eltoo vs. secruity budget

[Egge]

Hi everyone,

with Bitcoin halving the block subsidy every few years, we need one of two things to happen in order to secure enough secruity-budget for the mainlayer:
One is NGU. If the prices of Bitcoin rise, less stats will be sufficient to pay for mining hardware and electricity. If BTC/USD doesn't increase, fees nominated in sats/vB will need to rise. Either way main layer transactions will become more expensive nominated in "purchasing power", the more subsidy shrinks.

Personally I don't think this is a problem for the mainlayer. We were already able to witness mainlayer congestion a few times in the past and were are still so early. With more adoption, there will be more congestion and therefore a highly competetive fee market.

Now my question: I have just read "Blockstreams" paper on eltoo. They propose a second layer that waives the carrot/stick method of punishment by introducing state numbers, but the whole system still relies on OP_CSV and a honest peer enforcing the right state faster than a dishonest actor. But in a few years (or even decades) "fast" settlement might be very very expensive. A dishonest actor might be wiling to spend way more on mining fees, as they will be rewarded with their peers coins, if the attack is sucessful, while a honest actor will only loose money in a race against the attacker.

Did is misinterpret something? Is this problem already solved?

Thanks for your time!

[NotATether]

A dishonest actor can also set a smaller nSequence value inside an input they are spending to mess with the protocol. Normally, nSequence is set to the minimum number of confirmations. Then the script interpreter would assert that the nSequence of an input is smaller than the transaction's nLockTime.

The nLockTime cannot be tampered with in eltoo because it is part of a multisig transaction which the counterparty must also sign (so they would reject the transaction by not signing it).

But the problem here is that the person who signs the transaction LAST can set whatever nSequence they want since the other party has already signed, and therefore there is nothing they can do to prevent the broadcast (unless eltoo has already designed a safety measure for this). In a decentralized setting where you don't know which of the two parties is trustworthy, or whether either of them are, for that matter, it allows someone to violate the minim confirms condition.

But as I said earlier, maybe eltoo already has a guard against this, I did not study it completely.