@jude could it be possible that the address @shea256 is referencing is using an older release before the recent optimizations were made?
Regarding the graph from onstacks, i think it’s mostly in how the data is represented visually.
I’m also thinking jude is correct in that flash blocks can be a reason for what you’re seeing - consider the following graph, where the winning miner for 62411 (the only bar < 1000000 sats) is the foundation miner (which is very conservative):
It could be, but we don’t have a way of knowing at this time. Nodes don’t report to the world that they are miners (for security and privacy reasons). I suppose we could set up a series of “listener” nodes that actively seeks to determine where blocks originate from, but that would take some time (and given that the chain is making progress, I’m not sure that this is a high priority).
I did not say that anywhere – I was very careful not to, since that would be a lie. I said that the current release reduces the time to produce a Stacks block to 30 seconds (by default). This did cut down on the number of flash blocks, but it did not eliminate them (and I did not expect it to).
As for the “plausible explanations,” I’m happy to list some here since I’m not limited to a Tweet size:
The winning Bitcoin miner was not willing to consider the transaction, because it arrived too late or didn’t have a high enough fee for their liking.
The winning Bitcoin miner never received the transaction.
The node that produced the block-commit was not aware that the Bitcoin block they were targeting was no longer the Bitcoin chain tip (i.e. they were behind).
The node that produced the block-commit is out-of-date, and does not have the latest performance improvements that would reduce the likelihood of this event.
There is an unknown bug in the mining software that causes some block-commits to be delayed or mis-targeted
I think that the most likely explanation for as to why a miner is consistently mining empty blocks is because they have a configuration setting that prevents them from ever considering transactions. But there’s not much we can do about this either, since it’s an open-membership system where anyone can mine (and attempts to force miners to carry at least N transactions will simply cause a stubborn miner to include N of their own useless transactions, instead of N transactions from the mempool). We’ll just have to wait for the mining economy to wreck this miner, since they’re clearly making less money than the others.
EDIT: to be clear, I’m not trying to suggest that dealing with flashblocks isn’t important. It very much is. I’m suggesting instead that we don’t conclusively know why some miners miss some Bitcoin blocks, other than the fact that we’ve seen in the Foundation miner at least a tendency to miss sortitions when it discovers multiple Bitcoin blocks in rapid succession.
How fast would we need to produce blocks to eliminate flash blocks altogether?
Also, one of the things that’s confusing is that we have two problems. One is flash blocks and one is an “asshole miner” – the technical term I have heard used and not my word. Both of these appear as 1 tx on the explorer, the difference is the asshole miner is submitting only 1 tx per block when the sats per block is at a normal level. Once I understood this, I understood what you were talking about.
They’re getting RBF’ed. Stacks miners iteratively attempt to build better and better blocks as long as they are able to do so, but in order to update their in-flight block-commit, they RBF the old one with a new one with the better block’s hash.
The miner can control how long they will permit the node to try and build a block before sending a Bitcoin transaction. A larger value means that more transactions will be considered, but a higher chance that the transaction doesn’t get into the next Bitcoin block (a small value means the opposite – fewer transactions considered, but faster RBF rate).
I don’t know, but you can find out by looking at the successful block-commit rates for an empty-block miner versus a non-empty-block miner (i.e. look at how frequently an empty-block miner’s block-commits land in their target block, versus how frequently they do for someone who mines a non-empty block). You might want to start from the time at which release 2.05.0.2.0 was made, since that significantly sped up the time it takes to iterate through transactions.
I look forward to a time - pre or post v2.1 release - when @jude or other Hiro engr. can create some “inside Stacks v2.1” how-this-shit-works brain dump videos like we used to see during 2.0 development. We need to decentralized Jude’s brain cc: @muneeb@OwensTrevor@diwaker@shea256