Fix: correct burn view for miner block broadcast #5515
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]>
… cleanup even if it works
…cks-core into fix/burn-view
…ew-fix-burn-checks
…ew-fix-burn-checks
…checks Fix: explicit burnchain checks in miner thread
| match Self::can_continue_tenure( | ||
| &self.sortdb, | ||
| &mut self.chainstate, | ||
| sn.consensus_hash, | ||
| mining_pkh_opt, | ||
| ) { |
There was a problem hiding this comment.
Does can_continue_tenure need to be invoked here? After the recent changes to this PR, can_continue_tenure checks if there's a sortition in the most recent snapshot, and if there is, it returns None. I think this can just be replaced with return Some(MinerDirective::StopTenure) -- everything else is functionally dead code.
There was a problem hiding this comment.
Yes, I can remove this and just stop the tenure.
There was a problem hiding this comment.
I think this was a bad suggestion -- can_continue_tenure does return Ok(Some(..)) here in the event that the next tenure is a reorg, which is the correct behavior (and its roughly how the miner works in develop already). That's why miner_forking and tenure_extend_after_bad_commit started failing.
| /// We would do this if we were the miner of the ongoing tenure, but did not win the last | ||
| /// sortition, and the winning miner never produced a block. | ||
| /// Try to start up a tenure-extend. | ||
| /// Only do this if the miner won the last-ever sortition but the burn view has changed. |
There was a problem hiding this comment.
Should this say "the last valid sortition"?
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.