Uncommon two-block reorg on Bitcoin Mainnet

I did a quick search and couldn't find any talk about this unusual two-block reorg on Bitcoin Mainnet on the global boards here (though I did spot a thread in the German section). I came across it first on fork.observer and also verified it using bitcoin-cli getchaintips from my own Core node. Typically, I’ve only noticed one-block stale chaintips on Mainnet, so this is kinda new to me. You might think this is boring, but I was actually pretty stoked when I first noticed it a few days back. And it definitely brings up some questions. So here's what I found: My sources: bnoc.xyz/t/two-block-reorg-at-height-941880/97?u=b10c, nitter.poast.org/0xB10C/status/2036118084734349542#m What my node picked up seems to align with what’s being talked about in 0xB10C's thread, hinting at some selfish-mining by Foundry USA. There’s a more detailed time analysis here: bnoc.xyz/t/two-block-reorg-at-height-941880/97/13?u=b10c To me (and others), this looks a lot like Foundry USA intentionally doing some selfish-mining. I’m not trying to trash Foundry USA, but I find it fascinating why they decided to take the risk to outdo Antpool and ViaBTC, racing to get block 941883 and hopefully 941884 to secure their own blocks 941881 and 941882. They managed to mine seven blocks in succession: from 941879 to 941885. They took that chance and came out on top. Not everyone is thrilled about it, especially Antpool and ViaBTC, which is pretty obvious. Sources: bnoc.xyz/t/two-block-reorg-at-height-941880/97?u=b10c I don’t have a solid opinion yet, just some mining experience to go off of.

I do not see this as selfishness. Foundry USA has highest mining hash rates. I expect the mining pool to mine more blocks. Two stale blocks had occured before. Later one block will have the longest chain in each and become the valid blocks while the others will become invalid.

Foundry is not a private pool mining for itself. They do have a hash level number if you want to mine with them. I think it is 100ph minimum. I inquired in 2021 and was welcome to join the number I needed at that time was 20ph. Hash rate went way up since then so I am guessing that their minimum is 100ph. But it was 20ph in 2021. So if Foundry has hundreds of miners with  100ph or 20ph like me (I only have 3ph ) They have a legal obligation to whale at blocks as much as they can. Or face lawsuits from the 20ph or 100ph or 1eh miners using them.

It's also part of the issue I have pointed out here from the last time there was an issue with Foundry: At at guess they probably have so much security in front of their nodes that they didn't see the other blocks or the other blocks did not clear their security quick enough for some reason. All these checks going against the data they have coming in take a toll in terms of speed -Dave

I tend to disagree on this. Nope, see below. From anonymously provided Stratum work logs from Foundry (dig a bit at source) around blocks of reorg area, it's pretty much clear that Foundry was well aware of mined blocks by Antpool and ViaBTC. Foundry even mined for few seconds on top of each later staled Antpool and ViaBTC blocks, but quickly decided to persue on their own blocks. From carefully reading the discussion at above provided source, it's not water-tight selfish-mining, but it very much looks like a very intentional and deliberate choice. I mean, I don't blame them, they are the largest mining pool and certainly have no reason to be samatarians. But it shatters kind of my view of honest mining by established Bitcoin mining game theory.

Possible but don't forget about this: Foundry probably does not do any checking on their own blocks or anything internal to their network. When you are talking multiple seconds across firewalls and the internet they might not have fully validated the other block. For those of us running home firewalls and minimal filtering you never really see the slowdown. For a place like Foundry a real delay can exist. Even more so with multiple geographically dispersed nodes. Some of them may have actually been mining on the other blocks when they came back with their own and then started again. I can also see it happening because nobody on their end ever thought it could happen. And when it did, "well, that was odd, but it's never going to happen again" Not defending them, but I see sooooo much network slowdown due to tin foil hat paranoia settings on edge and internal security devices having something like this happen does not surprise me. -Dave

With Foundry only holding around 30% to a max of 40% of the global hash rate it is a rather large gamble for them to intentionally ignore a current tip of the chain and work from their last block. If the Antpool & ViaBTC blocks had been confirmed 3 times they and not Foundry would have 'won'. Not saying that some AI code (if they use any) might not choose to try it but I can't see Foundry having some dedicated supervisor/other authorized tech person monitoring the chain and periodically rolling the dice to try it. What was the timing of the blocks in reference to the one that tripped the reorg? Aside from being 2 blocks deep vs just 1 it could just be a normal orphan race, no? A bit perhaps unrelated, but was Foundry's block an empty one from the all too common practice of trying to shave off a little time by not fully validating the previous block? It also goes to show why protocol requires that a block needs >100 confirmations before coins in it and the fee paid to miner can be spent. Only after the >100 confirmations does the protocol make the block immutable. Considering that is only 16.8 hrs or so, not an intolerable time. Yeah in most businesses a block having only 3-4 conf's (or sometimes the tx even just appearing on-chain) is often considered 'confirmed' BUT it really isn't. The deeper into the blockchain they are, the safer they are BUT moving coins around on-paper from those tx's and assuming that they are valid must be done with the knowledge that it may change... Oh, of course it should be noted that as in any orphan race, the tx's in the now stale blocks just go back into the mempool, so they are just delayed a little bit more. BTW: the deepest (and only intentional) reorg was when the 184 billion BTC bug was tripped. Not sure how many blocks deep it was but because the chain was rolled back to a block just prior to the 2 offenders (block 74000 was the agreed upon last good one) I assume it covered the 5hrs of mining after the bug was tripped? Link to the BT thread here as the bug transpired only took 5 hours for the 2 tx's responsible to be voided through a forced soft-fork by Satoshi and Gavin.

If I can trust the mining stats of mempool.space then Foundry USA never has mined one of those infamous "empty blocks". I'm not sure about the exact timing of mined blocks and those that became stale later. There are some published details by 0xB10C and others in his blog which I provided a link to in my initial post. I also don't know how "global" Foundry's published Stratum work items are. Because disclosed Stratum work items from Foundry show that Foundry was well aware of Antpool's and ViaBTC's blocks and they even sent out briefly for very few seconds work to their miners where Foundry's miners mined on top of Antpool's block and also on top of ViaBTC's block. I probably don't see the whole picture, because it seems a bit strange to me that briefly Foundry acknowledges Antpool's block for a few seconds, even mining on top of it, but then deciding "na, we don't go on to mine on top of that tip, let's continue on our own chain of blocks". Repeating it again with ViaBTC's block, which Foundry very briefly acknowledged in the same manner as with Antpool's block. Who knows what the real timeline was from Foundry's perspective. Other nodes only see what their peers have seen and transmitted. There's probably no whole picture and propagation "truth" of the Bitcoin node network.

Going OT here... Came across a good paper from Jan 2024, https://research.mempool.space/empty-block-report/ Seems that up until publishing date both mara and Foundry have not ever mined an (edit: empty) block.   good for them! All other large pools have. Spiderpool and ocean both average 5% being empty... Kano's take on the matter https://bitcointalk.org/index.php?topic=5480549.msg63821149#msg63821149

Based on the timestamps, and the fact that both your and my nodes only saw the second block 941882 several minutes after it was found, I'd say it's plausible Foundry had a network disruption for a few minutes. But that does make me curious how the blocks reached their pool. If their pool found a block before a competing block reached them, it makes sense to continue mining on top of their own block. Why wouldn't they mine on top of their own block if they have one? They're supposed to stay honest because that's most profitable for them. If mining on top of their own block was the most profitable scenario, I'd say it still follows the game theory.

Hi!  I can imagine Antpool and ViaBtc's disappointment, but I wouldn't accuse FoundryUSA of selfish mining. Some users I asked about this said FoundryUSA simply got lucky and found a block a little early. Part of the network hadn't yet seen the competing block. They continued building a chain that looked correct. Then the network reached consensus on its own. FoundryUSA is the largest pool, if I'm not mistaken, so a streak of 2-3 blocks in a row is common. But 7 blocks in a row is the first time I've seen that, frankly. It's surprising, but I wouldn't call it selfish mining. To me, it's more statistics than strategy. Have a nice day everyone!  @Cricktor thank you for the interesting question, my friends and I discussed it for a long time.

You may want to correct your sentence to include the crucial missing word: "... have not ever mined an empty block." Recent data on this page https://mempool.space/graphs/mining/pools shows that MARA Pool has mined 4 empty blocks in the time frame between last 3-6 months. So, naturally your cited report from 2024 is outdated. Foundry USA has indeed so far never mined an empty block. Only 4 empty blocks for MARA is still a pretty low value. And yes, it's a bit off-topic. @LoyceV I have no data and evidence that Foundry suffered a network disruption. Foundry saw both later staled blocks from competing pools, even mined shortly on top of them (it's briefly mentioned in 0xB10C's blog according to broadcasted Stratum work jobs by Foundry). But for some reason Foundry quickly abandoned mining on top of foreign blocks. I can understand that because AFAIR Foundry found pretty quickly an own block 941881 (anchored to their own 941880) very shortly after Antpool's 941881. After this I don't remember atm the further facts. If I didn't get it wrong, it makes no sense to me if and that Foundry saw ViaBTC's block 941882 (anchored to Antpool's 941881) and presumably mined very briefly on top of it depending on the timestamps of arrival of Foundry's 941881 and later Foundry's 941882 and ViaBTC's 941882. To better argue, I will need to find the time and passion to compile timestamps from others what was published in the blog posts I provided links for. When Foundry found their block 941883 and later 941884 plus 841885 anchored to their own sequence of blocks, the fate of the foreign pool's blocks was sealed and the "foreign" two-block chain branch got staled. Foundry likely got a bit lucky, but there's still something odd, IIRC. But I need to compile the timestamps to better see the picture. May take some time as it's not the most urgent thing for me. My point is not to accuse Foundry. I just find it interesting and in the last few years where I watch and monitor the blockchain somewhat more closely a more than one stale block branch hasn't happened. It's very very rare and that makes it interesting to look even closer. Thank you all for your patience and contributions so far here.