Merit Removals in Blocks are a design antipattern.

[kayabaNerve]

Blocks aren't allowed to have Elements sharing a nonce. Instead, a Merit Removal is required. Malicious Verifications are allowed, due to packet signature aggregation, yet only if the matching Merit Removal is included. When there's three Transactions competing with each other, verifying the Merit Removals are included quickly become annoying, not to mention bloated.

The solution is to ban Merit Removals in Blocks. Instead, allowing malicious Verifications/Elements directly in the Block, and implicitly creating them. Not only does this allow finer control of implementation of Merit Removals, yet it also uses less bandwidth.

That said, we do lose Verification Packet Merit Removals, which are notable for directly specifying keys, instead of nicks. The intent of these is so if an aggregated signature is proposed with the most recent verifier, and a reorg knocks them out, the entire signature isn't invalidated.

I'm not personally concerned in dropping this feature, especially as it can be added back in the future via another part of the Block specifying arbitrary BLS signature data (such as an G1 + G2, FP12, or the messages to include outside of the consensus; the former are a fixed length and definite; the latter allows for more exploitation, yet is also simpler and provides context).

Due to Meros's timeline, I plan to actually keep Merit Removals around. When a Block is received, we can filter out the malicious Elements/manually add Merit Removals to the list of Elements. That, combined with banning parsing Merit Removals from inside the Blocks, should be a competent solution to quickly accomplish this task. The Python tests will properly verify accuracy, of course.

[kayabaNerve]

https://github.com/MerosCrypto/Meros/tree/implicit-merit-removals has been created for this.

[kayabaNerve]

Signed Merit Removals do suffer under this scheme. It's also not possible to broadcast a singular G1/G2 due to aggregation rules, and usage of any remote FP12 is unsafe as it'd cause any signature to pass as valid for any message. We'd need to include messages outside of the Consensus, as Merit Removal Verification Packets currently do.

That said, I still believe dropping MR VPs is best for Meros for now.

[kayabaNerve]

The new SyncManager code documents a new version of #120, this time with the archived Verifications.

[kayabaNerve]

VerificationPackets and Merit Removals are no longer Elements due to the lack of any advantage from such polymorphism (as they're no longer children in Merit Removals/stored in BlockBodies with their Elements). They are still present in that folder/exported by the Elements file though, to easily maintain compatibility.