Preventing stale state attacks in congestion situations

[tmjssz]

After a channel has been closed uncooperatively a timeout period starts, during which the counterparty can revoke the close request in case it contains an invalid balance. This mechanism brings up the following issue which has already been discussed for the raiden network: raiden-network/raiden#383

Problem Description

A particularly high transaction load during the timeout period could fill up all respective blocks so that the revoke transaction is delayed and the channel gets settled with incorrect balances. This situation could also be initiated by a stale state attack where the attacker closes a channel with an old state and instantly spams the network with a large number of empty on-chain transactions in order to delay the revoke transaction. Another attack scenario could be that the attacker closes many different channels with outdated balances at the same time resulting in many on-chain transactions. All the defenders who try to dispute their channel's close request would have to compete with one another for available block space before the block timeout ends.

In order to work on a solution for this problem, I created a small simulation of such an attack scenario: https://github.com/tmjssz/microraiden/tree/master/microraiden/stale_state_attack

Approach

One approach that that was already discussed in the raiden network issue follows the basic idea to prohibit an uncooperative channel close in congestion situations.

First, we need to become aware of a congestion. This could be achieved by addressing the problem the other way round: instead of actively detecting a congestion, we expect a proof that the blockchain is not congested. Such a proof must be provided by the participant who is willing to uncooperatively close a channel and is required to actually settle a channel with the given state. As a valid proof we define a number of x block headers which fulfill the following two conditions.

1. block number > number of block containing the close transaction
2. gasLimit - gasUsed >= gas required for revoke transaction

Despite our condition, that a channel can only be settled when the blockchain is uncongested, we still need a block timeout period because otherwise a closing party would possibly need to wait for an extremely long time to get refunded. This is problematic e.g. in case of an honest participant who wants to close a channel after the counterparty disappeared from the network. Hence, we need a mechanism to appropriately extend the timeout period when it did not contain enough block space for a revoke transaction.
Therefore, the following method is proposed: if the closing party can only proof y < x uncongested blocks as soon as the initial timeout period is over, the timeout period is extended by another number of m blocks which depends on the size of y. This is repeated for each time the extended period ends. If no proof is provided at that time, it is assumed that no uncongested block has been mined (y = 0). The size of m should decrease with the number y of proofed uncongested blocks. An equation expressing that logic is to be developed and the timeout extension outcomes are to be evaluated.

[vnblr]

Interesting discussion this (and the original raiden-network/raiden#383)
Some possibly fundamental questions. Please see if they make sense.

• In general, ability to know congestion status seems useful in many situations. Can't we leverage some oracle service using something like etherscan to get periodic basic metadata (maybe last n blocks average gas consumption/pending txs length etc) instead of asking each client to "prove" congestion?

• Assuming congestion is proven using any approach, I am a bit confused about how "settle" by sender will reach a miner before "close" by receiver given both will encounter congestion. Is it just because the settle can be given more gas price to prioritize mining?

[tmjssz]

In general, ability to know congestion status seems useful in many situations. Can't we leverage some oracle service using something like etherscan to get periodic basic metadata (maybe last n blocks average gas consumption/pending txs length etc) instead of asking each client to "prove" congestion?

That's an interesting proposal. This is how i understand your idea:

When "settle" reaches a miner (after the challenge period finished), the microraiden contract asks the oracle about the congestion status since the uncooperative "close". If a congestion is existing, the settle request is rejected.
How does the client notice when the congestion is over? Or would he just retry to settle the channel in fixed intervals, hoping that enough uncongested blocks were generated?

Assuming congestion is proven using any approach, I am a bit confused about how "settle" by sender will reach a miner before "close" by receiver given both will encounter congestion. Is it just because the settle can be given more gas price to prioritize mining?

Yes. If the "close" by receiver is sent with a higher gas price than the "settle" of the sender, the attack would fail.

[vnblr]

hi @tmjssz

How does the client notice when the congestion is over? Or would he just retry to settle the channel in fixed intervals, hoping that enough uncongested blocks were generated?

I think once there is a consensus on "how" congestion is detected, what do we do with it can follow any reasonable approach. For example, the client retries multiple times or we follow the logic in your note (where we extend timeout period if the chain is too congested). Basically I was just suggesting a globally acceptable way of noticing congestion, instead of asking the client to prove it. Once that hurdle is crossed, dealing with it can be a specific solution done on a case to case basis. Hope that makes sense.

Thanks

[vnblr]

By the way, I ran into https://ethresear.ch/t/extending-proof-deadlines-during-chain-congestion/84/17 which seems to discuss similar problem