Node sybil attack

Question

Assuming the chain is configured with:

anyone-can-mine = false
mining-diversity = 0
mining-turnover = 1

An attacker that has an address with mining permissions can launch an unlimited amount of nodes with the same address and thereby produce the majority of blocks. Even if mining-diversity is set to 0.5 an attacker can generate more blocks than other participants.

This is due to the fact that the random-timeout is per node and running multiple nodes with the same address raises the chances to be the first to sign the next block.

I understand that this is by design and that the admins could revoke the mining permissions of the attackers address after the fact. But it is an annoyance anyways.

Essentially currently there is no way to guarantee an equal distribution of blocks without the mining-diversity being set to 1. A mining-diversity=1 is impractical because block progress halts if one node is unavailable.

Are there any plans to somehow mitigate this problem?

One way to mitigate this would be to use a publicly available and independently verifiable "deterministic pseudo randomness" (like for example the hash of the last block) for ranking the next eligible block signers and accept lower ranking signers with an increasing timeout.

Answer 1

Yes, of course with mining-diversity=0, any miner can generate a block at any time, so this is not safe.

As for higher mining diversities, it's true that nothing prevents an attacker from generating more blocks than other participants, by always jumping in as soon as they get a chance according to the diversity constraint. But then, they have to wait until their turn again, so it doesn't do any damage to the overall consensus process. And unless there is some reward for creating a block, this type of "attacker" has nothing to gain.

Your idea of using the previous block's hash to choose the next block creator is interesting, although it is susceptible to manipulation as well. It might just be simpler to say that nodes don't accept one block too quickly after the previous one, and when presented with a fork they prefer the side with the miner whose last block was furthest in the past.  This rule cannot be enforced in terms of chain validity (since the arrival times of block is not a consensual fact), but at least it will encourage honest nodes to prefer forks from other honest nodes.

In any event, there is no ability in MultiChain to do this yet.

Comments

The order of past signatories determinining the preferred order of future signatories is definitely simpler but also has some implications:

The signers furthest in the past can collude by withholding blocks and presenting a stronger chain after the fact. Or nodes of signatories coming next in row could be attacked on the network level.

A selection of the next miner being revealed only together with the hash of the latest block might be harder to attack. But as you indicated this is still open to manipulation as, given enough time, a miner can influence the hash of the block he creates to his advantage.

Consensus under adversarial conditions is hard, and despite the irresponsible energy consumption Proof of Work has its virtues.

I am interested in any fuhrer ideas and suggestions in this matter.