-
Notifications
You must be signed in to change notification settings - Fork 1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Payloads: implement Conflicts attribute (#2818)
* Payloads: implement Conflicts attribute Closes #1991. * Update src/Neo/Ledger/MemoryPool.cs * Fix conflicting tx fees accounting Fix the comment #2818 (comment). * Reformat code and improve variables naming Fix Vitor's comments. * Make comments more clear and adjust variables naming Fix Owen's feedback. * Fix Conflicts attribute verification Consider the case when transaction B has the hash of transaction A in the Conflicts attribute and transaction B is on-chain. Let the transaction C has the hash of transaction A in the Conflicts attribute. Then transaction C still should be able to pass verification and should be accepted to the subsequent block, because transaction A isn't on chain and transaction A will never be accepted. Thanks to Owen for testing, this case is described at the #2818 (review). The expected behaviour in the described case is that TXID-D and TXID-E will be successfully accepted to the mempool and to chain, because the conflicting TXID-A is not on chain (and it's OK that the hash of TXID-A is on-chain as the conflicting hash). * Fix formatting, comments and add a testcase for conflicting mempool txs * Add one more testcase for conflicting transactions Testcase provided by Vitor in #2818 (comment). * Implement economic adjustments for Conflicts attribute Transaction that conflicts with mempooled transactions have to pay larger network fee than the sum of all conflicting transactions in the pool that have the same sender as the newcomer. Port the nspcc-dev/neo-go#3031. * Remove Trimmed value * Check signers of on-chained conflict during new tx verification Fix the problem described in #2818 (review). During new transaction verification if there's an on-chain conflicting transaction, we should check the signers of this conflicting transaction. If the signers contain payer of the incoming transaction, then the conflict is treated as valid and verification for new incoming transaction should fail. Otherwise, the conflict is treated as the malicious attack attempt and will not be taken into account; verification for the new incoming transaction should continue in this case. * Properly handle duplicating Conflicts hashes from the persisted transactions * Store signers of all conflicting on-chain transactions with the same Conflicts attribute Store not only signers of the latest conflicting on-chain transaction, but signers of all conflicting transactions with the same attribute. * MemoryPool: consider signers intersection on Conflicts check This patch should be a part of fd1748d, but was accidentally skipped. This patch matches exactly the NeoGo behaviour that was added in nspcc-dev/neo-go#3061 and that was discussed earlier in #2818 (comment). Fix the issue described in #2818 (comment). Signed-off-by: Anna Shaleva <[email protected]> * MemoryPool: add test for on-chain conflict Signed-off-by: Anna Shaleva <[email protected]> * Clean using * Refactor Malicious_OnChain_Conflict test Move it to the UT_Blockchain.cs file and refactor it a bit to make it actually pass as expected. Signed-off-by: Anna Shaleva <[email protected]> * Use Distinct to filter out duplicating conflicting on-chain signers Co-authored-by: Shargon <[email protected]> * Use HashSet as a container of conflicting hashes in the mempool Fix #2818 (comment). Signed-off-by: Anna Shaleva <[email protected]> --------- Signed-off-by: Anna Shaleva <[email protected]> Co-authored-by: Shargon <[email protected]> Co-authored-by: Vitor Nazário Coelho <[email protected]> Co-authored-by: Jimmy <[email protected]>
- Loading branch information
1 parent
5210728
commit 6398801
Showing
18 changed files
with
807 additions
and
51 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.