NO_DBL_VOTE does no kill the diagram as shown. NO_DBL_VOTE is activated only when the target (newer) checkpoints are different. As long as the target is the same, votes with different sources are not counted as double voting. The proposed solution does not remedy the situation. The diagram’s links spanning 2 dynasties only involve X whether the source or the target is concerned.
In your modified scenario, since B’s direct right child does not detect any justification link that reaches B, B’s right child and its descendants are not even justified. So your modified scenario does not pose a fork.
Thinking about it, one solution would be to make NO_DBL_VOTE rule stronger again, by banning citing different sources even for the same target. [Now I see it’s formulated like that already. Let me put it differently, until I found the above diagram, I wasn’t sure if NO_DBL_VOTE needs to punish different sources. Now I’m sure NO_DBL_VOTE needs to punish different sources.]
NO_DBL_VOTE does no kill the diagram as shown. NO_DBL_VOTE is activated only when the target (newer) checkpoints are different. As long as the target is the same, votes with different sources are not counted as double voting. The proposed solution does not remedy the situation.
Wait, what?
NO_DBL_VOTE is activated if there exist any 2 distinct votes that have the same target epoch.
I changed NO_DBL_VOTE in Cancun after I gave my talk because I found that there was no reason to punish two votes with the same target epoch, same target and different source epochs. That change caused problems with dynamic validator sets.
In the current implementation, slashed validators are not removed from the denominator for the current dynasty; they are only removed from the denominator for the next dynasty (and future ones).
The whitepaper says that when a validator is slashed then its entire deposit is taken away. It would be nice to provide a clarification on application of slashing to the current set of competing sub-trees
I am just trying to get a feeling whether it is feasible to “resurrect” a validator deposit, by going to a historic minority tree where the deposit was not slashed, and applying mining or PoS power to grow this tree into a winning tree. With enough mining power could this be done in-between checkpoints?
Is the following algorithm correct:
A validator uncovers a slashing condition.
A validator submits a slashing violation transaction to the Casper smart contract.
The deposit is slashed on the tree that is used by the block proposer when the slashing transaction is included by the block proposer.
Taking the above algorithm it is not obvious to me that the deposit is ultimately slashed on all trees, it is also not obvious that it is impossible to “resurrect” the deposit by growing an alternative historic tree …
What is is the best way to think about deposit slashing in terms of multiple competing trees?
There is indeed an assumption that slashing transactions will be included into all chains within some period of time, and it is up to clients to enforce this. (Why would they? Well if a 51% miner coalition suddenly started not accepting any regular transactions, then the community would probably soft-fork away that chain too).
Mechanisms for doing this in a way that maximally preserves consensus are an open research problem.
From the practical point of view, would it make sense for a validator to resend the slashing transaction if detects that it is not included in the currently winning chain.
I think one could imagine a situation where:
A slashing transaction is sent by a validator
A good miner includes it in a block, so it is not anymore in the pending transaction set of the good miner
After a while, a powerful bad miner comes and grows an alternative chain, where the deposit is not slashed
The alternative chain becomes the winning chain
The validator notices that a chain is winning where the deposit is resurrected
The validator resumits the slashing transaction
The good miner includes it in the winning chain
I think for the validator it makes sense to make the resubmission, since if the deposit is resurrected, the validator bounty is taken away.