Hey I’m seeing this on https://app.onstacks.com/ right now and I’m trying to figure out what’s going on. This seems like quite a bit of miner inconsistency when it is normally more consistent.
Are Bitcoin miners blocking / not taking up certain transactions? Is the light blue miner selectively mining blocks? Are they having issues with their servers? Are they free mining?
@jude any thoughts?
Flash blocks
I don’t think this is Bitcoin flash blocks.
It doesn’t explain why only SP2G20 regularly skips one every several blocks.
I think this is worth investigating.
Something fishy may be going on here.
@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):
I thought you fixed flash blocks and this was a miner intentionally mining only 1 tx (i.e. an asshole miner)?
You also said, “there are lots of plausible explanations, but they’re not really that important,” which implies you don’t know what’s causing it.
So is it flash blocks or is the real answer that we don’t know what it is?
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:
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.
Got it, thanks for the clarification.
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.
A large % of the transactions going to my stacking address are being cancelled.
Is this normal miner behavior?
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.
OK just making sure that’s what’s going on and not some strategic miner behavior.
It seems that two miners in particular are cancelling and re-sending transactions more than others.
I wonder if they have a different version of the software.
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).
OK so is there any advantage for miners who do not include any transactions and mine empty blocks?
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