What does having 51% of online voting weight allow an entity to do?

I thought it might be useful to have a clear outline of what someone with 51% online voting weight can and can’t do on this forum.

Please correct any misunderstandings and add any I haven’t mentioned.

They can’t :

  1. Roll back transactions on other nodes
  2. Modify account balances
  3. Added * They can't prevent services throwing their node offline to avoid multi-spends

They can :

  1. Censor blocks (transactions, rep change blocks)
  2. Added * They can attempt multi-spends by sending each service a different set of votes for different forks of a source block
  3. Added * They can freeze the network indefinitely
4 Likes

I believe your can't mentions are accurate. With the can ones, it is worth noting that censoring blocks can come in the form of refusing to vote for blocks, so they won't be confirmed.

Some additional things they could potentially do:

  • They can attempt multi-spends by sending each service a different set of votes for different forks of a source block
  • They can freeze the network indefinitely

An additional can't:

  • They can't prevent services throwing their node offline to avoid multi-spends

And note that these items could be resolved by the network if non-malicious nodes were to update their node software to ignore the maliciously identified voting weight and any subsequent movement of that voting weight. This would obviously be a big task to undertake, but getting to 51% ownership of voting weight on the network is extremely difficult to begin with thanks to the design of the ORV consensus mechanisms.

9 Likes

When you say “attempt multi-spend“, what are some ways that receivers would be able to mitigate this risk?
Are you referring to checking transaction persistence with their own node?

The receivers can't do much, it falls on node operators to define how much quorum they would require to confirm a transaction. If someone has 51% of online weight, setting quorum higher to, say, 80% would ensure you need more legitimate votes.

3 Likes

Increasing the quorum is not something we tend to talk about much.
I’m trying to understand the consequences.
It refers to the the minimum online voting weight required for the node to vote at all, correct?
If my node has a higher (eg 80 million) quorum in my config and the online weight dropped to 70million which is above 60million (default for most) would this result in my node simply not voting and be considered “down”, or does it return a “decline to vote” which tells the network it is still up but refusing to vote?

1 Like

The mention of increasing quorum requirements is actually related to raising the % of voting weight required to consider a block confirmed by the network. This would make it so a node would only locally confirm a block if more than just the attacker voted for it and isn't a broad solution to the issue during a 51% scenario.

The minimum online voting weight you mentioned wouldn't help in this case I don't believe. Once weight goes below this minimum, I don't think there is a mechanism to signal you are at that point - the voting continues but locally the blocks won't be confirmed on your node. Once weight is back online the local confirmations are then resumed.

2 Likes

Is there a config that stipulates what percentage on online weight needs to agree on a transaction’s validity? Or is 51% majority likely to be the only workable majority?

Yes, online_weight_quorum defines requirements to win an election.

1 Like

I’m trying to understand what the tradeoffs are in raising this across the board to a higher value.
It would in theory increase the cost and difficulty of undertaking a majority vote attack.
I must be missing something very simple here.

If this is raised then more voting weight would need to be tallied before it is considered confirmed. This means potentially longer confirmation times as you wait for more votes to come in to hit the higher % of online weight.

@Dotcom Can you confirm that if this is turned up too high you may never get confirmations? More specifically, if the rest of the network has quorum at a lower value and blocks are confirmed by the fastest votes quickly, will those voting nodes that haven't voted by the time they see enough weight to confirm the block on their side even attempt to vote at that point?

We can think of this as a process that could be done outside the node. You would query the RPC for the votes on a block, then accumulate the total weight on it. Based on the weight, you decide if it's confirmed or not.

It would be a function of:

  1. The votes received
  2. The online voting weight on the network
  3. The desired quorum

Available weight this is basically the available supply and excluding how much Nano has been burned. We only know for sure about amounts sent to the "default" burn address. This is around 133 million.

Online weight not all online weight is assigned to principal representatives (101 million out of 102 million, close enough).

In the node we use the online weight, not total available weight, otherwise it would take more votes than necessary to confirm a block. We only need 50%+1 of the currently voting weight, and this is tracked by listening to votes and marking that weight as online. Every 10 minutes we sample the weight, and what we effectively use in the end is a trended value over 2 weeks to avoid jumps (e.g., if a representative is offline for maintenance).

So, in the node we confirm a block if 50% of the trended online weight has voted for our block. Currently, this is 101 million from PRs, let's round that to 100 million.

Normally, we then only need 51 million weight on a block to confirm it. There are 2 scenarios that complicate this:

Suddenly, a large PR goes offline. If 10 million of the 100 million online goes suddenly offline, our trended online value remains around 100 million for a while. Therefore, we still require 50 million on a block, but now only 90 million are available. If a total of 50 million goes offline, then you have no confirmations until the trended value is adjusted. If you increase the required quorum (e.g., 90%), then confirmations stall earlier. Stall resistance is seen here: https://repnode.org/representatives/resistance

Suddenly, a large PR comes online. A PR with 30 million weight was offline for a long time and now comes back online. The trended value is still 100 million, but there are 130 million going around. If this new representative is malicious, then you are only "protected" by another 20 million. With an increased required quorum (e.g. 90%), you are more protected, but if more than 10% (in that case) is voting maliciously, then you might not see confirmations either.

In the end, we also have a minimum online weight to prevent edge cases and protect the nodes, and in all scenarios, it takes a large amount of weight to vote maliciously to create a problem.

2 Likes

50%+1 actors can cause forks by rolling back blocks.

Imagine an account has frontier F and previous P (both confirmed). An attacker could refuse to confirm block A turning block B into the frontier. Old nodes would refuse that change but new nodes would not.

If the owner of the account refuses to accept the rollback he will never transact again (malicious actor refuses to confirm blocks that have F as frontier) and if he accepts the roll back and generate a new block N with previous P, the old nodes will have their chain P -> F while new nodes (that bootstrapped after the malicious actor took over) would have their chains P -> N, both equally confirmed.

Block B (a fork of Block A with the frontier as previous) can only be produced by the account owner themselves using the private key to sign, so this doesn't appear to be possible.

1 Like

Sorry, I did not make it clear, the malicious actor can't create the fork on his own, but he can force the account owner to choose between never sending a valid block again (by never confirming it) or to accept the rollback and sign a new block forking his own frontier. This causes a fork instead of a double spend because existing nodes would not accept the newly confirmed block since it would replace a block that is cemented in their ledgers, but new bootstrapping nodes would accept the forked version as the one valid.

So the fork would happen between previously existing nodes and new nodes.

Ah, I see. At the point someone has over 50% voting weight the damage would be so severe that this attack likely wouldn't make too much sense, but could technically be done yeah. If an attacker attempted to convince the account owner to fork a previous block back when their balance was higher and send to a new address that the attacker owns, the account owner might do this if the resulting balance after that new spend was still more than the current frontier (so deeper in the ledger). But of course the old nodes won't respect this, so those funds wouldn't be spendable with anyone using an old node which is where all exchanges, etc. would likely remain.

2 Likes

Yes, I was just brainstorming on possible outcomes of someone owning 50%+1.

EDIT: The attacker could do this to every account whose frontier is not a send, to maximize the number of network users who would accept and support his behavior to avoid him shutting down the network completely.

EDIT2: The above works only to receives whose link is not a frontier, but it's does not matter at this point, it's too confusing for no benefit. He could just require every account with a balance to send him X% of their balance or he won't confirm their blocks. That is easier and has the same effect. I guess it just boils down to shutting down the network.