Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests: Improve p2p tx propagation functional test #9762

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

tests: Improve p2p tx propagation functional test #9762

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 26 additions & 10 deletions tests/functional_tests/p2p.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,12 +160,11 @@ def test_p2p_reorg(self):

def test_p2p_tx_propagation(self):
print('Testing P2P tx propagation')
daemon2 = Daemon(idx = 2)
daemon3 = Daemon(idx = 3)
daemons = (Daemon(idx = 2), Daemon(idx = 3))

for daemon in [daemon2, daemon3]:
for daemon in daemons:
res = daemon.get_transaction_pool_hashes()
assert not 'tx_hashes' in res or len(res.tx_hashes) == 0
assert len(res.get('tx_hashes', [])) == 0

self.wallet.refresh()
res = self.wallet.get_balance()
Expand All @@ -175,12 +174,29 @@ def test_p2p_tx_propagation(self):
assert len(res.tx_hash) == 32*2
txid = res.tx_hash

time.sleep(5)

for daemon in [daemon2, daemon3]:
res = daemon.get_transaction_pool_hashes()
assert len(res.tx_hashes) == 1
assert res.tx_hashes[0] == txid
# Due to Dandelion++, the network propagates transactions with a
# random delay, so poll for the transaction with a timeout
timeout = 16
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vtnerd Do you know the expected maximum propagation delay in this scenario, based on the D++ paper? That value would act as an approximate lower bound for the timeout, which could then be further padded to reflect physical realities of data transmission and processing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The delay should usually trigger the inbound fluff delay where it's using a poisson distribution, simply mimicking what Bitcoin was doing for the same situation. 95% of the values are in the 3-7.3 second range. A delay of 16 is basically nearly impossibl, so this should be acceptable.

As an explanation of why not exponential here - one of the nodes will have no outbound peers. I don't recall the paper stating how to handle the situation, so I decided to make it immediately fluff, as it would be an edge case. A fluff does randomized poisson delays, similar to what Bitcoin was doing at the time. I don't recall the d++ specifying how to handle fluff precisely either, maybe I need to revisit that paper.

pending_daemons = set(daemons)
expected_hashes = [txid]
wait_cutoff = time.monotonic() + timeout
while True:
done = []
for daemon in pending_daemons:
res = daemon.get_transaction_pool_hashes()
hashes = res.get('tx_hashes')
if hashes:
assert hashes == expected_hashes
done.append(daemon)
pending_daemons.difference_update(done)
if len(pending_daemons) == 0:
break
max_delay = wait_cutoff - time.monotonic()
if max_delay <= 0:
break
time.sleep(min(.25, max_delay))
npending = len(pending_daemons)
assert npending == 0, '%d daemons pending' % npending


if __name__ == '__main__':
Expand Down
Loading