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

Fix: correct burn view for miner block broadcast #5515

Open
wants to merge 27 commits into
base: develop
Choose a base branch
from

Conversation

jcnelson
Copy link
Member

This fixes the burn view calculation for the Nakamoto miner when accepting and broadcasting a block.

It builds atop #5508, so don't bother merging until #5508 is in develop.

@jcnelson jcnelson requested a review from a team as a code owner November 27, 2024 20:15
@aldur
Copy link
Contributor

aldur commented Dec 3, 2024

  1. Merge hotfix: remove chain stall race condition #5508 to master
  2. After release merge master into develop.
  3. Merge this to develop.

jferrant
jferrant previously approved these changes Dec 4, 2024
@jcnelson
Copy link
Member Author

jcnelson commented Dec 5, 2024

This now contains the hotfix to the miner @obycode @jferrant

@@ -66,6 +66,9 @@ use crate::run_loop::nakamoto::{Globals, RunLoop};
use crate::run_loop::RegisteredKey;
use crate::BitcoinRegtestController;

#[cfg(test)]
pub static TEST_MINER_THREAD_STALL: std::sync::Mutex<Option<bool>> = std::sync::Mutex::new(None);
Copy link
Collaborator

Choose a reason for hiding this comment

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

could use TestFlag here if you wanted.

)
{
if ongoing_tenure_id.burn_view_consensus_hash != sort_tip.consensus_hash {
todo!();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we have an issue for this? D: If we plan to leave a todo! in the code, would be good to add a message to it.

/// sortition, make sure we first mine a tenure-change block and then a tenure-extend block.
#[test]
#[ignore]
fn test_tenure_change_and_extend_from_flashblocks() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am prob just misunderstanding the test, but I don't see any confirmation about a tenure change/extend being issued in the correct order in this test. Is the fact the follower boots up and the chain advances proof enough?

Copy link
Collaborator

@jferrant jferrant left a comment

Choose a reason for hiding this comment

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

Just a few questions.

@aldur aldur added this to the 3.1.0.0.2 milestone Dec 11, 2024
@jcnelson jcnelson requested a review from a team as a code owner December 15, 2024 04:48
@@ -960,6 +980,7 @@ impl BlockMinerThread {
self.burn_election_block.sortition_hash.as_bytes(),
)
} else {
// TODO: shouldn't this be self.burn_block.sortition_hash?
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's resolve this TODO in this PR. I'm not immediately sure what the correct answer is.

Copy link
Contributor

@obycode obycode left a comment

Choose a reason for hiding this comment

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

This looks good. Just had some minor comments. I want to run this through some more live network testing before feeling 100% confident.

Comment on lines +718 to +719
/// (1) 2 block commits have been issued ** or ** more than 10 seconds have
/// passed since (1) occurred
Copy link
Contributor

Choose a reason for hiding this comment

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

This is copy-pasted from these other methods, but I think it should say:

Suggested change
/// (1) 2 block commits have been issued ** or ** more than 10 seconds have
/// passed since (1) occurred
/// Mine a bitcoin block, and wait until a block commit has been issued
/// ** or ** more than timeout_secs seconds have passed

Comment on lines 403 to 408
let stacks_tip = StacksBlockId::new(&cur_stacks_tip_ch, &cur_stacks_tip_bh);
let highest_tenure_start_block_header = NakamotoChainState::get_tenure_start_block_header(
&mut self.chainstate.index_conn(),
&stacks_tip,
&cur_stacks_tip_ch,
)
.expect(
"Relayer: Failed to get tenure-start block header for stacks tip {stacks_tip}: {e:?}",
)
.expect("Relayer: Failed to find tenure-start block header for stacks tip {stacks_tip}");

let stacks_tip_sortition =
SortitionDB::get_block_snapshot_consensus(&self.sortdb.conn(), &cur_stacks_tip_ch)
.expect("Relayer: Failed to load canonical Stacks tip's tenure snapshot")
.expect("Relayer: Canonical Stacks tip has no tenure snapshot");
Copy link
Contributor

Choose a reason for hiding this comment

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

Neither of these variables are used. I think they can both be deleted.

.map_err(|e| {
error!("Relayer: failed to get last snapshot with sortition: {e:?}");
// Get the necessary snapshots and state
let burn_tip = SortitionDB::get_block_snapshot_consensus(sortdb.conn(), &new_burn_view)?
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is used any where.

Comment on lines 1030 to 1032
let Some(mining_pkh) = self.get_mining_key_pkh() else {
return Ok(());
};
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Status: In Review
Development

Successfully merging this pull request may close these issues.

4 participants