How to protect Plasma against DoS attacks?

[kladkogex]

Ok - good Now I understand ) I think this can be a way to address the issue.

[PaulRBerg]

Couldn’t this be gamed? I know one of the biggest assumptions in Plasma is root blockchain availability, but in the example discussed here Eve might be able to cheaply pull off a successful attack.

1. Eve makes 1,000,000 intermediate UTXOs
2. Eve tries to exit all these UTXOs and attaches a bond to each one of them, the gas cost + some bounty
3. Immediately afterwards, Eve pulls off a spamming attack which lasts at least as long as the challenge period. This attack needn’t bloat the network, but just make gas costs higher than the bond in each UTXO so there’s a disincentive to challenge her fraudulent behaviour.

I guess this can be prevented by making the challenge period reasonably high, thus forcing Eve to pay a lot to keep the spam on-going, and efficiently calculating the bond costs. I’m not sure how the latter could be achieved though.

Point 3 could also be improved if Eve load balances her spam by cleverly waiting for the market to organically slow down the network. Running a Plasma chain after CryptoKitties launched would’ve been rather problematic.

[kladkogex]

Good point! Looks like bonds are not going to secure things.

[MihailoBjelic]

@PaulRBerg I think you might be on the right track to a valid attack model here.

I guess this can be prevented by making the challenge period reasonably high

But the longer the period, the worse the UX for the honest users gets. IMHO, even the current 7 days challenge period could turn out to be a big problem. How many people used to e.g. centralized trading platforms/exchanges will accept to wait 7 days to withdraw their funds?

and efficiently calculating the bond costs

I believe bond requirements would have to be calculated dynamically, and I would surely love to see that mathematical model. I don’t like to be negative, but I think that is close to impossible to design. Also, even if we assume that we have such a model, if it calculates that (some of) the exits should require 10ETH bonds (we assume that that calculation is correct from the security point of view), that will also completely ruin the UX for the honest users…

[kfichter]

Immediately afterwards, Eve pulls off a spamming attack which lasts at least as long as the challenge period. This attack needn’t bloat the network, but just make gas costs higher than the bond in each UTXO so there’s a disincentive to challenge her fraudulent behaviour.

Actually exiting 1,000,000 UTXOs is hard (and costly) but I agree that this is problematic and we need better models around bond prices. Mainly we should be looking at exactly how high these bonds need to be to prevent this sort of behavior. Assuming a bond is fixed at X ETH and a challenge costs Y gas, it’s simple to determine when the explicit reward of challenge will be negative. How much would it cost to drive gas prices up that much for the entire challenge period?

Generally I don’t think static bonds cut it, but I’m also not aware of any efficient method for determining the current gas price. In reality there are probably some external incentives (companies want to keep user funds safe) we can take advantage of, but I’d rather capture these in the protocol.

This problem also exists in Plasma Cash (I think), although it’s probably logistically harder to set up. You’d also have to target one person in particular.

[MihailoBjelic]

I’m also not aware of any efficient method for determining the current gas price

Isn’t it trivial to determine the current gas price by simply looking at the Txs in the last block (number of blocks)? Maybe I’m missing something obvious…

Even if I’m right and you can easily determine the gas price at a certain moment X and calculate the bond according to that (I assume we have a good, working model for this), the problem is that the attacker can start spamming and pumping the gas price e.g. 48 hours after that moment X. The (only) two solutions for this:

1. Ask everyone to top up their bonds when the attack starts (UX nightmare)
2. Introduce some buffer multiplier from the beginning, e.g. if the model calculates the bond size of 0.05 ETH, we ask for 5x0.05 ETH instead (less scary UX nightmare )

[PaulRBerg]

Actually exiting 1,000,000 UTXOs is hard (and costly)

This is very much true, setting up the attack initially described by @kladkogex is a logistical ordeal, but I think we always should assume that the worst scenario can happen and will happen if we let it.

How much would it cost to drive gas prices up that much for the entire challenge period?

Many factors at play here, but the attacker could act cleverly and corroborate on random, organic bloats of the main chain.

Isn’t it trivial to determine the current gas price by simply looking at the Txs in the last block (number of blocks)? Maybe I’m missing something obvious…

@kfichter was saying that, despite the latest gas price in the most recent block, there’s still absolutely no guarantee that the next block won’t contain a list of transactions with attached fees worth ㆔1 each if someone is willing to spend that amount of money. Presuming normal conditions though, indeed, the last block might be a good proxy for estimating the gas prices, but this thread has been presuming horror conditions, not trivial or rational ones.

Method 1 is indeed a UX nightmare and method 2 might be a scary model from an economic standpoint. If I know there’s always the threat of paying double or triple or more to get my funds back to Ethereum, I wouldn’t even deposit on Plasma in the first place.

Perhaps the optimal solution is to have a model where the operator is able to top up the bonds of every undercapitalised exit. He can afford to periodically scan the Plasma contract for any spooky exits and the main chain for sudden gas cost increases. The presumption here is that the operator has a strong incentive to keep the Plasma chain running, because the cost of a successful attack would be higher than the summed topped up bonds. Afterwards, they could impose slightly higher fees on Plasma to amortise these expenses. Now, there is an elastic limit of how much the bond top-ups can be, but there’s a relatively similar limit to the main chain’s attack size, hence I intuitively feel that these two vectors eventually cancel out.

[MihailoBjelic]

@kfichter was saying that, despite the latest gas price in the most recent block, there’s still absolutely no guarantee that the next block won’t contain a list of transactions with attached fees worth ㆔1 each if someone is willing to spend that amount of money.

Oh, then we were speaking about the same thing. Thanks.

Perhaps the optimal solution is to have a model where the operator is able to top up the bonds of every undercapitalised exit.

This is an interesting idea but, as you said, we have to assume that the operator is incentivized to keep the Plasma chain running (correctly). This is a dangerous assumption IMO, since the operator might be the attacker, so her interest very well might be not to top up undercapitalised exit, or to top up only some of them.

[sule]

@PaulRBerg @kladkogex what do you think about banning Eve temporarily or indefinitely after trying to pull certain number of successfully challenged invalid withdrawal attempts?
Individual users with whom Eve was creating micropayment transactions may not have good enough incentive to challenge her but general incentives for anyone could be calculated in cheap and efficient manner. And it would make impossible to perform this kind of attack.

[kfichter]

what do you think about banning Eve temporarily or indefinitely after trying to pull certain number of successfully challenged invalid withdrawal attempts?

Not sure how you’d do this if Eve makes a different address for each exit.