On superblock double voting

[aesedepece]

This is related to #1949 and #1389.

Double voting is the case in which one Witnet identity votes for two different superblocks for the same superepoch.

This is normally seen as a problem, because the whole 2/3rds assumption in our protocol (and many other protocols) is based on the idea that it is impossible for two different tips of the chain to get 2/3rds votes majority. For that assumption to hold, each identity must only be allowed to vote for one tip of the chain at a time.

In our case, AFAIK, if we receive 2 or more votes for different tips from the same identity, we drop both votes.

But at this point I don't see double voting as a problem for our protocol.

My personal take is that as long as we can define a protocol-level deterministic algorithm for prioritizing superblock double votes, this is a no-problem and we can start "double dropping" the double votes, which is not a penalty to the double voter but a penalty to the network as a whole, because odds are that many times you'll end up dropping an otherwise valid vote.

For example, we can define that in case that one identity voted multiple times, we always count and re-broadcast the vote with the lowest hash. If everyone follows this logic, the "worst" vote will fall flat and simply won't make it any further. On the contrary, the "best" vote will be propagated as usual.

I'm specially interested in @clbartoli and @mariocao chiming in, because they are the most aware about the assumptions that were taken when we last defined our strategy on double voting.

[drcpu-github]

I remember we had this discussion on Discord a while back where miners are not punished for double voting for different superblocks. I'm a bit wary of essentially letting miners just do whatever they want without repercussions. I can imagine there are scenarios where miners could collude in order to get their chain of events accepted by voting for multiple superblocks at the same time (either because this increases their rewards or because they try to manipulate data requests).

[aesedepece]

I was simply not trying to distinguish them for now.

When I said "at this point I don't see double voting as a problem for our protocol", I really meant "without penalties, there's no reason to drop double votes, we can resolve them deterministically".

As per the broader goal of introducing penalties... I can't simply think of a way that is not vulnerable to an attack in which votes from other miner factions are intentionally censored so as to trigger slashing on them.

[drcpu-github]

When I said "at this point I don't see double voting as a problem for our protocol", I really meant "without penalties, there's no reason to drop double votes, we can resolve them deterministically".

Agreed on this. The proposed solutions to resolve them deterministically rather than drop them sound fine if we do not deem it a problem for the protocol.

As per the broader goal of introducing penalties... I can't simply think of a way that is not vulnerable to an attack in which votes from other miner factions are intentionally censored so as to trigger slashing on them.

I don't think we should necessarily conflate double voting (which potentially makes sense to punish) and not voting (which could be due to censorship as you point out and that makes it dangerous to dole out injust punishments).

[aesedepece]

I don't think we should necessarily conflate double voting (which potentially makes sense to punish) and not voting (which could be due to censorship as you point out and that makes it dangerous to dole out injust punishments).

Interesting point. We can't assume that double voting and no voting will be treated the same when considering penalties.

[drcpu-github]

I think the high-level analysis of this issue comes down to whether we want to handle double voting differently from not-voting.

As you already point out in your intial reaction, the point can be made that not voting can be malicious, because you don't want the result of a certain transaction to be confirmed. However, given that it also could be the result of censorship, it may be difficult to punish. The question then becomes how likely it is that this is because of censorship? At a certain network size, it seems unlikely that you are connected to only malicious peers and if you are not, your vote will spread exponentially through the network. From that perspective, I would be inclined to say that censorship is unlikely enough to be a significant problem (and it may be worth exploring punishing this too).

Of course, if the most common case of double voting can also be attributed to reasons beyond a node operators' control (such as peering / synchonization issues), it may prove difficult to justify penalizing node operators for double voting. Double voting could definitely be used for transaction censoring too. I also think it could be used to try and mine a separate chain of blocks and try to force these in (which would be worse in my opinion), so I think double voting may require a higher priority if we think about punishing that.

One other issue I'd like to bring up (and I'm playing the devil's advocate here) is that whether directly penalizing nodes is a defensible position to take if we don't directly reward superblock voting, but that is likely again a separate discussion topic.

[aesedepece]

It is true that countermeasures for censorship are already in place and so we may rule out that possibility (e.g. bucketing)