This was originally caused by a single line in the protocol docs, specifically the violations section.
Meros doesn't check that if VerificationPackets in a Block cause MeritRemovals, the matching MeritRemoval is included in the Block.
I was hoping to implement this within a few hours. That said, it quickly became more complicated. If you have TXs X, Y, and Z, which all compete, you need to create 'MeritRemoval's for all of them. The protocol both only cares a removal happens, and requires tracking each individual one. Because we need to not handle the same Merit Removal multiple times, we need to process X/Y, Y/Z, and X/Z. That said, this quickly becomes unscalable.
The simple solution, which is what this was about, was just to have each Merit Holder only have one Merit Removal, before permanently banning them. That's the first major feature of this, and the primary feature. The namesake feature is that Blocks no longer have MeritRemoval objects. Rather, they directly include the elements (the competing verifications or elements sharing a nonce).
The protocol docs have been minimally touched. Multiple Python tests about complex behavior have been removed, as this is a much simpler system without an equivalence. The State and Consensus DAGs have the most changes.
Merit Removals with transactions not applicable to the current DAG, which used to be supported, are no longer. Merit Removals based off Verification Packets are also gone, yet their inclusion on chain can be done via the Block's packets; this does remove the functionality where the keys were specified, instead of nicks, in case of re-orgs and premature signature aggregation + pruning.
Closes https://github.com/MerosCrypto/Meros/issues/252.
This was originally caused by a single line in the protocol docs, specifically the violations section.
Meros doesn't check that if VerificationPackets in a Block cause MeritRemovals, the matching MeritRemoval is included in the Block.I was hoping to implement this within a few hours. That said, it quickly became more complicated. If you have TXs X, Y, and Z, which all compete, you need to create 'MeritRemoval's for all of them. The protocol both only cares a removal happens, and requires tracking each individual one. Because we need to not handle the same Merit Removal multiple times, we need to process X/Y, Y/Z, and X/Z. That said, this quickly becomes unscalable.
The simple solution, which is what this was about, was just to have each Merit Holder only have one Merit Removal, before permanently banning them. That's the first major feature of this, and the primary feature. The namesake feature is that Blocks no longer have MeritRemoval objects. Rather, they directly include the elements (the competing verifications or elements sharing a nonce).
The protocol docs have been minimally touched. Multiple Python tests about complex behavior have been removed, as this is a much simpler system without an equivalence. The State and Consensus DAGs have the most changes.
Merit Removals with transactions not applicable to the current DAG, which used to be supported, are no longer. Merit Removals based off Verification Packets are also gone, yet their inclusion on chain can be done via the Block's packets; this does remove the functionality where the keys were specified, instead of nicks, in case of re-orgs and premature signature aggregation + pruning.
SignedMeritRemovals are untouched.
PR is meant to undergo review.