So what you are doing is essentially discarding new blocks associated with duplicate stakes.
I approve of this decision. It is not a full resolution of nothing @ stake though.
There are two distinct of nothing @ stake issues.
-
The possibility that miners will mint on every fork they see to maximize block output.
-
The possibility that someone who owned a whole bunch of coins in the past will build on the distant past.
You certainly cover the first. The second issue is much trickier and Iām not sure if you have it covered. Letās examine the second issue for a moment.
Suppose for example, that pirate held 51% of all coins at some point in the past. He didnāt, but you could see how this might happen. Pirate was supposed to have held 20%. Given that only a fraction of stake actively mines, even 20% could be enough.
Pirate no longer owns these coins, but decides to take them back. To do this he uses his 20% of coins to build a private blockchain. If the % of miners actively mining on the main chain is less than 20%, eventually pirate will overtake the main chain. A checkpoint, of course, could prevent this.
I donāt think you can address this issue with your system duplicate stake detection. If you apply duplicate stake detection over a long-time range, miners will get stuck on a fork when they download the wrong block (or set of blocks) by accident. Ways of addressing this issue include:
- Checkpoints
- Downloading candidate blockchains in their entirety. Computing a set of suspect inputs associated with duplicate stake or double-spending within the candidate blockchains. Recalculating total chain difficulties for each blockchain after subtracting out blocks signed by the set of suspect inputs. Selecting the true blockchain based on the recalculated total difficulties.
(2) is essentially a form of long-range duplicate stake detection. I donāt think Vitalik is aware of this option. I also donāt think any blockchains are using a system like this right now.
