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.

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

When a new burn block is mined; fast blocks should stop progressing (Integration) #5232

Open
5 tasks
Tracked by #5133
ASuciuX opened this issue Sep 24, 2024 · 0 comments
Open
5 tasks
Tracked by #5133
Assignees

Comments

@ASuciuX
Copy link
Contributor

ASuciuX commented Sep 24, 2024

To check:

  • tenure height updated + 1
  • next_block_consensus_hash != current_block_consensus_hash
  • submit burn block -> imediately submit a tx, then wait 5 secs, then new tx.
    • check /v2/info / or most recently process blocks.
    • good cases:
      • 1 old consensus hash and 1 new consensus hash
      • both 2 new consensus hash
    • bad cases:
      • both 2 old consensus hash

TODO: Integration tests that should try the above cases
Look into: multi-miner integration tests
Stall nakamoto-runloop:


  • Test 1:
    • Miner A and B -> call miner A runloop to stall
    • All signers look into miner A -> all signers don't see the update
    • => miner and signers don't update block

  • Test 2:
    • Miner A and B -> call miner A runloop to stall
    • All signers look into miner B -> all signers see the update
    • => only miner A doesn't update block, the signers and miner B update
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Status: 🆕 New
Development

No branches or pull requests

1 participant