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

Miner should generate a tenure-extend and continue mining if the next miner does not start mining #5361

Open
obycode opened this issue Oct 22, 2024 · 6 comments

Comments

@obycode
Copy link
Contributor

obycode commented Oct 22, 2024

Currently, the miner will generate a tenure-extend and continue mining if there is no sortition in the next burn block, but it should also do this if there is a sortition, but the next miner does not mine a block within some threshold time.

@obycode
Copy link
Contributor Author

obycode commented Nov 1, 2024

Sometimes, the next miner is unable to mine any blocks, so the previous miner should be able to tell for sure that it can extend its tenure. This happens if the winning miner's block commit is not committing to the correct tenure. Sometimes this will happen if a miner's block commit is not RBFed in time. #5064 could help with this, avoiding the need for an RBF.

@obycode
Copy link
Contributor Author

obycode commented Nov 1, 2024

If a miner sees that the next miner is in this situation, it should go ahead and immediately submit a tenure extend.

@obycode
Copy link
Contributor Author

obycode commented Nov 1, 2024

I think this scenario is happening often currently in mainnet, causing pauses in block production. One example I looked at:

  • 1730421788.150710: 868333 arrives
  • 1730421788.918551: Miner submits a block commit committing to 179741
  • 1730421790.755410: Tip advances to 179746
  • 1730421792.239285: Miner builds 179746'
  • 1730421811.364948: Signers reject 179746' because the last miner built 179746 already
  • 1730421812.605401: Miner builds 179747
  • 1730421824.720642: 179747 is approved and tip advances
  • 1730421825.640789: attempt to RBF block commit, committing to 179747
  • 1730421849.696787: burn block 868334 arrives, including the original block commit

@obycode obycode self-assigned this Nov 9, 2024
@obycode obycode moved this from Status: 🆕 New to Status: 💻 In Progress in Stacks Core Eng Nov 9, 2024
@aldur aldur modified the milestones: Nakamoto-3.0.x, Tenure extend Nov 14, 2024
@obycode
Copy link
Contributor Author

obycode commented Nov 14, 2024

#5452 solves the case where the winner has a bad block commit. This is the common case that we currently see on mainnet, so it is the more important one to solve.

The timeout case will be done in a separate PR, but there is already an integration test ready for it, tests::signer::v0::tenure_extend_after_bad_commit tests::signer::v0::tenure_extend_after_failed_miner, though not enabled in bitcoin-tests.yml.

@hstove
Copy link
Contributor

hstove commented Nov 14, 2024

The timeout case will be done in a separate PR, but there is already an integration test ready for it, tests::signer::v0::tenure_extend_after_bad_commit, though not enabled in bitcoin-tests.yml.

Typo I think, the non-enabled test is tenure_extend_after_failed_miner

@obycode
Copy link
Contributor Author

obycode commented Nov 14, 2024

Ah, you're right thanks! I'll edit the earlier comment to avoid confusion later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Status: 💻 In Progress
Development

No branches or pull requests

4 participants