feature_blocksign.py: Allot for possibility of non-empty block 0.5RTT #747
Conversation
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
stevenroose
added a commit
that referenced
this pull request
Oct 16, 2019
…block 0.5RTT fcc7051 feature_blocksign.py: Allot for possibility of non-empty block 0.5RTT (Gregory Sanders) Pull request description: The way the test is run, the last node(non-signer) can actually become the block producer. This, in conjunction with its p2p connection to node 0, means that when node 0 is doing it's compact block back and forth, it can actually create a complete block in 0.5 RTT even if transactions were generated for that block. Allow this to happen. This may have been a bug in that the non-signer shouldn't have been making blocks, but this is actually more interesting behavior to test, where sometimes partially-complete compact blocks are made, sometimes full, sometimes empty. This exercises more code paths, and so I'm just making sure this succeeds instead, and assert it only succeeds in the expected situation. Tree-SHA512: f6267208c51344a26636fce4635297f050e2989ec231d2d21463e9a987b58d0a8635bea057b60216fa709ca094cf741ce8acfc0b1d321b6498409c73a19c8fd1
|
ACK fcc7051 |
This was referenced Oct 16, 2019
instagibbs
added a commit
that referenced
this pull request
Oct 22, 2019
…-empty block 0.5RTT 128d7e0 feature_blocksign.py: Allot for possibility of non-empty block 0.5RTT (Gregory Sanders) Pull request description: Backport of #747 Tree-SHA512: 9d5aaeb47bc595975fd45269aa2d2d99f943a4dc53739791e558a3eb682c08c60cc7bf761c6c4e230d919c8e4da3926738b8c8655ec4bc02a3f7ce9c65d3361e
apoelstra
added a commit
to apoelstra/elements
that referenced
this pull request
Nov 6, 2020
apoelstra
added a commit
to apoelstra/elements
that referenced
this pull request
Nov 9, 2020
apoelstra
added a commit
to apoelstra/elements
that referenced
this pull request
Nov 10, 2020
stevenroose
pushed a commit
that referenced
this pull request
Mar 16, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way the test is run, the last node(non-signer) can actually become the block producer.
This, in conjunction with its p2p connection to node 0, means that when node 0 is doing it's compact block back and forth, it can actually create a complete block in 0.5 RTT even if transactions were generated for that block.
Allow this to happen.
This may have been a bug in that the non-signer shouldn't have been making blocks, but this is actually more interesting behavior to test, where sometimes partially-complete compact blocks are made, sometimes full, sometimes empty. This exercises more code paths, and so I'm just making sure this succeeds instead, and assert it only succeeds in the expected situation.