-
Notifications
You must be signed in to change notification settings - Fork 677
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
base: develop
Are you sure you want to change the base?
Conversation
|
…tenure nor extend the ongoing tenure, and fail-out of continue_tenure
…cks-core into fix/burn-view
Signed-off-by: Jacinta Ferrant <[email protected]>
@@ -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); |
There was a problem hiding this comment.
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!(); |
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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?
There was a problem hiding this 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.
…nction, and drop unused code
…cks-core into fix/burn-view
@@ -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? |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
/// (1) 2 block commits have been issued ** or ** more than 10 seconds have | ||
/// passed since (1) occurred |
There was a problem hiding this comment.
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:
/// (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 |
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"); |
There was a problem hiding this comment.
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)? |
There was a problem hiding this comment.
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.
let Some(mining_pkh) = self.get_mining_key_pkh() else { | ||
return Ok(()); | ||
}; |
There was a problem hiding this comment.
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?
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
.