-
Notifications
You must be signed in to change notification settings - Fork 671
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
Reliability improvements: UTXO chaining breaks after miner commitments miss intended burnchain block #2358
Comments
The smoothing function is only taking the commits from the canonical fork, not from the bitcoin chain. So, different burn values are expected on different branches/forks. |
There's two things at work here, the second of which is, I believe, a bug -- First, miner commitment windows are evaluated by Bitcoin block (not Stacks block), so when miners skip mining in a block, the consequence is that the commitments won't get counted for that block. In the example block The node only detects two transactions from that Bitcoin block having any history of burns in that window, blocks in the range (666655-666650]:
The second issue at work in that block, which I believe is a bug, is that in order to evaluate a mining window, the stacks-node needs to be able to associate each commit with that miner's previous commits. To do this it uses UTXO chaining. However, the stacks-node only tracks UTXOs for valid Bitcoin operations. That means if the previous commit was an invalid commitment, it wouldn't normally be tracked. However, #2177 attempted to address this by allowing missed commits to still be tracked and therefore the "chain" of UTXOs not to be dropped. Unfortunately, it seems like there is a bug in this handling of MissedBlockCommits (https://github.com/blockstack/stacks-blockchain/blob/master/src/chainstate/burn/operations/leader_block_commit.rs#L687) uses the absolute intended burn height, whereas it should use the relative burn height (i.e., |
As a consequence bitcoin miners can delay a commit tx and thereby reset the stacks miners probability to win. |
#2383 should be limiting the impact of that bug |
Try polling your bitcoin node more frequently. It's |
it is set to poll_time_secs = 1, is this value provide the most frequent polling? |
…each missed block commit's intended sortition, instead of failing to find the sortition.
This is fixed in |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Describe the bug
Burn values for 1K1rSXoxAaJPQdWpm6XgZ6xwzkikxmWonW are 1 even though the miner is burning regularly.
Another example:
Take an example where there were two adjacent stacks blocks that were mined by exactly the same participants. Blocks 449 and 450. 449 was mined on burn block 666652 and 450 off 666655
53 and 54 were skipped for whatever reason
The sortition playing field for block 449 looks like this
222k miner is the winner here
the rest of the field looks pretty healthy contribution wise at this point
we then skip blocks #666653 #666654
and this is the field for the next block
same participation as the prev block, but apart from the leader of the previous block everyone else has had their commit history truncated back to 1
Stacks dump:
Expected behavior
** Additional context**
The text was updated successfully, but these errors were encountered: