Duplicated blocks from same pool : detection and punishment

[vincenthz]

Duplicated blocks creates painful and unnecessary forks on the network.

We want to disincentivize this working setup as this lead to selfish local earning improvement at the expense of the overall network

The first step will lead all node to actually keep track of duplicated blocks they receive from the network and keep proof of bad behaviour from pools.

The second step will lead to the node of the network communicating on this behaviour and taking collective actions akin to a temporary punishment that will reduce the earning of this pool for a given period of time

Furthermore, we don't to punish a single odd duplicated block mistake, but only the repeated offender.

[arussell29]

Great to see this being addressed! Would it be possible to just prevent a pool operator from starting two pools with the same secret, or maybe quarantine one of the instances once two identical leaders are detected?

[boem74]

must leave the wallet.

[mark-stopka]

@arussell29 and what's stopping someone from commenting out the "advertise I am a pool" message in the code and building own version of Jormungandr? The proposed solution makes a lot of sense, there will be 3rd high priority topic used to distribute duplicate blocks among nodes, when they have evidence of double minting, they can take action and temporarily reject blocks signed by the same pool. The cool-off period can increase exponentially.

Trust-less, although not long term solution, long term solution needs to record the information on chain, which given the size will need a zkSNARK or some other small zero-knowledge proof.

[arussell29]

@mark-stopka I think good solutions that require the least amount of additional code or modifications are often the better way to proceed. I left my suggestion in case there was an easier, perhaps unconsidered, route to stopping adversarial forks. I completely leave it up to the devs to solve this important problem in whatever way is most efficient for them and that also adheres to the coding philosophy they follow. Thank you.

[benapetr]

This punishment sounds too complex to implement, I would follow simple policy similar to when pledge isn't met - detected duplicate = loss of rewards for entire epoch.

Detecting "single odd duplicate blocks", first or second offenders etc. is just over-engineering, also there is no such a thing as "single odd malicious behavior", you could as well ignore "single odd pledge inconsistency".

[benapetr]

Also the communication blocking is overengineered and inefficient solution, you can't even know for sure which relay truly belongs to the pool. There are staking pools as a service providers, that operate hundreds of pools behind shared infrastructure and single set of relays.

[mark-stopka]

This punishment sounds too complex to implement, I would follow simple policy similar to when pledge isn't met - detected duplicate = loss of rewards for entire epoch.

Detecting "single odd duplicate blocks", first or second offenders etc. is just over-engineering, also there is no such a thing as "single odd malicious behavior", you could as well ignore "single odd pledge inconsistency".

What punishment is used is the easiest part of all that, the difficult part is the construction of a cryptographically sound way to put proof on chain.

[benapetr]

I don't think it's possible to have a proof on single chain, because only one of blockchain forks (the longest one) will survive and the blocks with duplicate slot id are only physically present in discarded chains.

I agree that this is hard to verify properly. At least someone more "official" like IOKH devs could release a statement that this kind of behavior is indeed malicious and harmful for the network, because right now when you post anything about a pool that does this, half of the people involved will be asking why is this a problem and if it really is a problem

[mark-stopka]

I don't think it's possible to have a proof on single chain, because only one of blockchain forks (the longest one) will survive and the blocks with duplicate slot id are only physically present in discarded chains.

Well, you are wrong, other chains solved it long time ago, and there are several ways to do it.

I agree that this is hard to verify properly. At least someone more "official" like IOKH devs could release a statement that this kind of behavior is indeed malicious and harmful for the network, because right now when you post anything about a pool that does this, half of the people involved will be asking why is this a problem and if it really is a problem

You can find statement about that directly in the Ouroboros Praos paper.