-
Notifications
You must be signed in to change notification settings - Fork 100
Preventing stale state attacks in congestion situations #477
Comments
Interesting discussion this (and the original raiden-network/raiden#383)
|
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.
Yes. If the "close" by receiver is sent with a higher gas price than the "settle" of the sender, the attack would fail. |
hi @tmjssz
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 |
By the way, I ran into https://ethresear.ch/t/extending-proof-deadlines-during-chain-congestion/84/17 which seems to discuss similar problem |
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.gasLimit
-gasUsed
>= gas required for revoke transactionDespite 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 ofm
blocks which depends on the size ofy
. 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 ofm
should decrease with the numbery
of proofed uncongested blocks. An equation expressing that logic is to be developed and the timeout extension outcomes are to be evaluated.The text was updated successfully, but these errors were encountered: