Trade-offs when handling re-org attacks

Development and Technical Discussion
1

Note

This is an action point from the last dev meeting:

Description

Beam recently announced repeated 51% attacks on their network that resulted in exchanges being defrauded.

Since it’s possible that Grin will become target of a similar attack at some point in the future, it’s worth to consider our options.

There are two main options, each coming with their own set of trade-offs:

  1. EITHER: keep the “longest chain rule” intact, and do not introduce any checkpoints. This makes it easier to 51% attack a chain with low hashpower. If this happens or is at risk of happening, you will then need to instruct exchanges and vulnerable services to increase their confirmation times for transactions. They may not follow your advice, and people and services may lose money. You try to ride out the attacks as best you can. This can create a negative death spiral, where: Chain has low hash power → Gets attacked successfully → Confidence in chain is lost / exchanges delist → Chain gets even less hash power → Attacks become easier … etc.

  2. OR: introduce checkpoints of some sort where re-orgs beyond a certain horizon are no longer possible. This leads to the longest chain rule no longer being sound. It is harder to 51% attack, but it becomes much easier for an attacker to force a network split. This then introduces a centralization point where some group of people determine which chain to follow after a split occurs.

Beam ended up implementing a rolling checkpoint mechanism (option 2 above) that prevents re-orgs from happening that are deeper than 60 blocks. The “longest chain rule” is no longer valid beyond that threshold.[1]

They also increased the required amount of confirmations to 70, or 80.

While it is now harder for these 51% attacks to continue, it is easy for an attacker to force their network to split, something which can happen repeatedly.

What should Grin do?

The “longest chain rule” is a fundamental principle of nakamoto consensus, and is ultimately what is allowing the network to automatically decide which chain to follow, removing the need for a trusted authority to instruct the network on which chain is the “right” one.

In the meeting, which everyone is urged to read the notes from, the general consensus was:

Grin would rather suffer a 51% attack than adopt an unsound longest chain rule.

Do you agree?

Opinions for/against, as well as other ideas are welcome.

[1] Beam added an exception to this reorg rule, which states that if the current tip has seen no progress in the last hour, then deep reorgs are allowed.

This so that after a chain split, if one side is abandoned by miners, then nodes on that side will rejoin the other side automatically.

This mechanism can be prevented by an attacker that continues to mine the chain, as long as they can bring difficulty down fast enough to avoid a >1 hour block.

Therefore forcing a manual intervention.

10 Likes
2

I think there’s value in strictly following the consensus rules “no matter what” even when it would be very convenient not do so. I’m definitely against changing the consensus even if Grin gets 51% attacked.

5 Likes
3

Nice meeting. Many interesting things that were discussed.

I tend to option 1. As I think this problem will solve it self when Grin grows bigger. For now I firmly believe Grin is in good hands with the core. If anything bad happens they (will have to) manually pick the right chain. In the process of doing that they will most likely waste most of the attacker’s efforts to attack the chain. In time, when Grin grows, the 51% attack would be a lot harder. Intervention should then not be needed anymore. You don’t need to make checkpoints. Do not break consensus. We trust the core but consensus is the holy foundation beneath them.

I would rather see a form a ‘hotline’ were certain parties can connect to the core and receive signals when a chain is being attacked or other abnormalities are detected. We should be able to signal that within seconds to exchanges. They are then able to halt trading and freeze wallets. Killing more efforts of the attacker.

4

Under no circumstances should Grin move away from PoW for consensus.

2 Likes
5

While both Grin and Beam use MimbleWimble transaction format, but in case of PoW attacks the only PoW algo matters. Beam uses a variant of Equihash, and 51% attacks on Equihash blockchains happen quite often. And ASIC-resistant chains are usually weaker.

It works like this:

-> A chain with bigger here (Zcash or something). An attacker has only small part of hashrate here.
-> A chain with significantly smaller hashrate but mineable with the same hardware. The attacker has enough hashrate here for an attack. The attacker switch their farm to the smaller hashrate chain, maybe replaces mining software (in some cases, the attacker can just rent hardware).

As Grin uses also a ASIC-friendly PoW as ASICs appears Grin is safe. At least while it has top in a specific hardware niche.

Even without the ASIC miners, Grin should be somehow safer than Beam because of the two PoW algorithms with different hardware requirements. But there is a threat anyway.

I think it’s better to stay with the original consensus while it is possible. What happens in Beam not necessarily to happen in Grin. But if attack happens to stay with no changes in consensus will be not very sane as attacks can repeat again and again.

1 Like
6

I also agree on this.

Possible new project if anyone wants to help:

  • design a web page, possibly we could do it on Grinnode.live, which monitors the hash-distribution and block mining distribution.

  • set a threshold which tells everyone to start their GPU GRIN-Miners, even one “old” GPU might help prevent 51% attack if we all start mining at a specific time.

10 Likes
7

I think it will be good to understand the distinction between “mining for consensus” and “mining for distribution”. If non-PoW or hybrid consensus can be implemented with minimal changes (or no changes) in monetary properties, it can bring benefits.

But avoiding consensus changes is better anyway.

8

Good to see this discussed and well articulated in a forum post. Thanks, @lehnberg

It’s encouraging to see most of the community are on the same page. Option 1 FTW

No checkpoints are a feature. Especially from an ideological perspective when you’re trying to create a decentralized currency.

2 Likes
9

Also, while there are no ASICs, maybe implementing opensource FPGA mining firmware can help.

10

I think changing consensus could be devastating to the confidence of the project.

Mining for consensus can be decentralized. The devs picking the “proper chain” is centralized.

11

Hardforks are also consensus changes and there was few.

12

We all agreed on 4 hard forks. Anything past that will require significant consensus to achieve.

1 Like
13

Roughly an attacker that does a 51% attack can do either of the two following things:

  1. He only replaces the transaction being attacked with his double spend transaction, and keeps in his reorg all the other transactions that do not relate to him
  2. Attacker is more brutal and does not include any of the original transactions that were in the blocks being attacked.

Usually, 1. is preferable for an attacker which is only financially driven, since most of the users remain unaffected by the attack, which may imply less panic and less despair from users, and as a consequence a smaller loss in dollar / bitcoin value of the blockchain following the public information of the attack.

According to what I understood, Beam has been subject to the attack of type 2.

Something to notice with respect to 51% attacks on a Mimblewimble blockchain is that attacks of type 1. are technically quite more difficult to perform. It in particular necessitates that the attacker kept with him the kernel offset of the transaction he is double spending. If he did not do so, the attacker will have no choice but to make an attack of type 2.

In order to make attacks of type 1. easier to perform, we might think to implement wallet functionalities that make them easier (saving kernel offsets for example), but of course this comes with its own set of trade offs, and might incentive attacks on Grin as a result.

Overall, @mcm-mike has come with a great proposal to improve awareness of the mining communities on Grin security. It is exactly the kind of things that could benefit Grin in this context, and I hope his proposal will gather good momuntum and come to fruition.

2 Likes
14

Processing txs takes time so it’s probably easiest and most effective to mine empty blocks. I imagine #2 is much more common. It would only make sense to include txs if there were substantial fees to take.

It also seems complicated to have your secret split chain and have to wait for the legit chain to mine a block to see what made it into the block so that you could keep all other txs intact.

15

@mcm-mike this is a great suggestion. It’s closely related to the other action items we discussed in the meeting: Chain split mitigations action items · Issue #327 · mimblewimble/grin-pm · GitHub

  • Set up monitoring of our p2p network in order to detect any attacks.
  • Create a tool / formula for on the fly calculation of attack cost or risk of attack.

If you and others want to help with this is it could do wonders to our abilities to detect when attacks are imminent or underway.

This will be important regardless of the direction we go. :+1:

4 Likes
16

Something I’ve learned today from the discussions around 51% attacks on ETC. Say that the attacker publishes the chain that makes a very deep reorg. Let’s say that this reorg is X blocks longer than the original chain. The miner software could when it sees a big reorg estimate whether it makes sense to continue mining on the current chain or switch to the attacker chain. This isn’t a consensus rule change, it is just picking what to mine which everyone is free to do. If the attacker was 15 blocks ahead, then it would take 16 minutes to reorg back the network which would mean the attack was not successful. It really depends on “how long it takes to reorg back” here, but is a possible strategy that might actually make sense. The miners are also incentivized to keep mining the old chain so they can keep their rewards.

TLDR; I still don’t think it is possible to prevent a 51% attack because it happens almost instantly and you have no time to react. But the window to reorg it back might be short and this might be the preferable option to go for.

1 Like
17

Perhaps a small funding request could be a good idea here, to ensure this gets completed.

Ideally there should be a key contact at major exchanges which an automated messaged goes out to each time a single entity has >51% of the hashrate, alerting them to consider pausing/ freezing all deposits. This might not work in practice, however, at-least Grin would be taking a proactive approach to protecting exchanges getting caught out.

^From an exchange perspective; if you’re going to support small cap PoW alt coins there must be a point where you either 1) delist the coin, or 2)consider some kind of protection mechanism that auto freezes all trading pairs under x conditions pending manual review.

2 Likes
18

It looks problematic right now.

51% of the last 100 blocks of 32/29z have gone to an unknown entity. with Circa 51% of C32 available on Nicehash.

image
image1448×476 62.6 KB

1 Like
19

When Grin will be compromised it will be over. For Grin it will be finish.

20

Hopefully ASICs turn up soon to save us then.