"Ethereum Casper FFG PoS, like all PoS consensus protocols, is vulnerable to bribery censorship attacks."

[jamesray1]

@dankrad

Maybe you need to ask a more specific question if you want to get a reply on this.

I edited my post.

@dankrad

It seems like the two statements are correct, however they do not respond to the specific way in which @vbuterin was addressing the attack, which was at the time the attack is detected. In this case, no reversion of a finalized chain occurs – the finalization essentally stalls until the attack is resolved one way or the other. Does that clarify things for you?

I’m unconvinced. It looks like you’re responding to the finality reversion section of Vitalik’s post. However, in the soft fork bribery attack, it is proposed that it can be done by punishing validators who fail to participate in enforcing punishments

More generally speaking, I think the issue needs serious consideration, even to try to simulate or prove that such an attack can occur, and shouldn’t be readily dismissed. Given that PoS blockchains aim to secure billions in value, all possibly attacks should be thoroughly investigated as a priority, rather than BAU R&D. If an attacker can gain control of the network through this kind of attack, once they gain control this becomes stable, and it’s intractably hard to take back control. I think anyone responding in this thread should read the above articles here, and here and Vitalik’s post, if they haven’t already. (I’m not saying you didn’t, but just to be sure.)

TBH, I hadn’t read through all of Responding to 51% attacks in Casper FFG.

The problem with trying to have evidence of censorship attacks is that even if the censorship attack is real, that doesn’t necessarily mean the history rewrite we are using to recover is 100% honest. It could have a double-spend attack embedded in it. It could be the case that the attacker is simultaniously doing a soft fork bribery attack to censor txs on-chain, and he is also doing a history re-write attack to do some double spending, and he can use evidence of the first attack to justify executing the second attack. So whichever side of the fork we go with, one of the attacks succeeds.

The false flag attack is a possible scenario/mechanism that it seems like it could potentially be used to attack the minority fork of a chain that attempts to recover from a 51% attack (like a censorship attack, aka a soft fork bribery attack).

I don’t have a lot of time to assess this further, as I: 1) am currently looking for a job 2) have already spent a lot of time volunteering for projects like Ethereum and Holochain 3) Am convinced that Holochain is better than blockchains.

Just wanted to flag to the Ethereum community that maybe they should spend some more time assessing this attack, as I don’t know whether it has been thoroughly disproved or resolved.