Page MenuHomePhabricator

[avalanche] Delay polling the conflicting transactions
ClosedPublic

Authored by Fabien on Mon, Apr 28, 10:17.

Details

Reviewers
roqqit
Group Reviewers
Restricted Project
Commits
rABCfa8168048c22: [avalanche] Delay polling the conflicting transactions
Summary

THe actual behavior is to poll for the mempool transactions and the conflicting transactions. The latter is actually not strictly needed: if a conflicting transaction exists, then there is an associated transaction living in the mempool. Because we pull back the conflicting transactions if the mempool one is rejected, it will naturally be polled as well when it reached the mempool.

This simplifies the logic and avoids some edge cases because mempool transactions have computed all the properties to check if they will fit in a block, despite conflicting transactions don't.

Test Plan
ninja check-extended

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Fabien published this revision for review.Mon, Apr 28, 11:02
roqqit requested changes to this revision.Mon, Apr 28, 20:11
roqqit added a subscriber: roqqit.
roqqit added inline comments.
test/functional/abc_p2p_avalanche_transaction_voting.py
505–506 ↗(On Diff #53720)

the names should be swapped to make this more clear. otherwise the comment at line 476 does not make sense.

This revision now requires changes to proceed.Mon, Apr 28, 20:11
test/functional/abc_p2p_avalanche_transaction_voting.py
505–506 ↗(On Diff #53720)

I disagree, the name is correct. Conflicting refers to the network decision, just like it is for the previous case. The fact is that both txs go in/out the mempool/conflicting pool over the test so the name is always wrong at some point, but it matches the final avalanche decision.

This revision is now accepted and ready to land.Thu, May 1, 19:36