Open kayabaNerve opened 3 years ago
Meros is a very complex protocol, and in my years of working on it I have written up several notes on tests that should be added.
[ ] Invalid signatures aren't considered valid. This actually happened at one point in time when we switched Ed25519 libraries.
[ ] Burn address ([0] * 32) can't have signatures verified for.
[ ] Mints can't have Verifications created for them. This may need to be partnered with a clarification in the protocol docs.
[ ] Sends which use a Mint/Data as an input fail (and the same for Datas + Mints/Sends).
[ ] Send/Data Transactions are checked against their current difficulty.
[ ] Send/Data Transactions have their difficulties scaled according to their size.
[ ] Meros always generates Send/Data Transactions with a valid spam proof.
[ ] Meros consistently verifies new Datas (using an empty hash as the input) as well as Block Datas (using the genesis).
[ ] 0 Merit Verifications. Happens when TX X is only verified once, yet its verifier has their Merit die.
[ ] Competing TXs X and Y where X would win due to MH Z, yet Z gets their Merit removed in the same Block as finalization. Does Y win?
[ ] Signed MeritRemovals based on Verifications which can no longer be added to the chain are dropped.
[ ] BlockHeaders must beat the difficulty, when syncing and when reorg'ing.
[ ] BlockHeaders can't have a non-existent miner nickname (related to https://github.com/MerosCrypto/Meros/issues/106).
[x] Blocks can't have multiple packets for the same Transaction.
[ ] Blocks can't contain the same Element multiple times.
[ ] Blocks can't contain Verifications for Transactions whose parents have yet to have an on-chain Verification.
[ ] Only Transactions which obtain a majority of Merit cause rewards.
[x] When syncing a total Block List, Meros includes the genesis hash.
[ ] Rejection of messages whose length exceeds 8 MB.
This issue will serve as a up-to-date list of pending tests.
Can supersede:
https://github.com/MerosCrypto/Meros/issues/106 https://github.com/MerosCrypto/Meros/issues/131 https://github.com/MerosCrypto/Meros/issues/189 https://github.com/MerosCrypto/Meros/issues/216 https://github.com/MerosCrypto/Meros/issues/239
" BlockHeaders must beat the difficulty, when syncing and when reorg'ing." is partially tested via #273.
Meros is a very complex protocol, and in my years of working on it I have written up several notes on tests that should be added.
[ ] Invalid signatures aren't considered valid. This actually happened at one point in time when we switched Ed25519 libraries.
[ ] Burn address ([0] * 32) can't have signatures verified for.
[ ] Mints can't have Verifications created for them. This may need to be partnered with a clarification in the protocol docs.
[ ] Sends which use a Mint/Data as an input fail (and the same for Datas + Mints/Sends).
[ ] Send/Data Transactions are checked against their current difficulty.
[ ] Send/Data Transactions have their difficulties scaled according to their size.
[ ] Meros always generates Send/Data Transactions with a valid spam proof.
[ ] Meros consistently verifies new Datas (using an empty hash as the input) as well as Block Datas (using the genesis).
[ ] 0 Merit Verifications. Happens when TX X is only verified once, yet its verifier has their Merit die.
[ ] Competing TXs X and Y where X would win due to MH Z, yet Z gets their Merit removed in the same Block as finalization. Does Y win?
[ ] Signed MeritRemovals based on Verifications which can no longer be added to the chain are dropped.
[ ] BlockHeaders must beat the difficulty, when syncing and when reorg'ing.
[ ] BlockHeaders can't have a non-existent miner nickname (related to https://github.com/MerosCrypto/Meros/issues/106).
[x] Blocks can't have multiple packets for the same Transaction.
[ ] Blocks can't contain the same Element multiple times.
[ ] Blocks can't contain Verifications for Transactions whose parents have yet to have an on-chain Verification.
[ ] Only Transactions which obtain a majority of Merit cause rewards.
[x] When syncing a total Block List, Meros includes the genesis hash.
[ ] Rejection of messages whose length exceeds 8 MB.
This issue will serve as a up-to-date list of pending tests.