Rare two-block reorg in Bitcoin Mainnet

[Cricktor]

A brief search didn't reveal a discussion about a rare two-block reorg in Bitcoin Mainnet in international boards here (German local board has a topic on this). I've seen this for the first time on https://fork.observer and in output of bitcoin-cli getchaintips from my online Core node. Normally only one-block stale chaintips are visible on Mainnet, from what I've seen so far and I can't claim to have seen it all.

You might yawn at this, but I was a bit excited when I first observed it a few days ago. And it raises questions.

Here's what I'm talking about:

Sources: https://bnoc.xyz/t/two-block-reorg-at-height-941880/97?u=b10c, https://nitter.poast.org/0xB10C/status/2036118084734349542#m


Here's what my node saw which seems to match what is discussed on 0xB10C's thread as a likely example of selfish-mining by Foundry USA.

Code:

2026-03-23T15:43:24Z Saw new header hash=00000000000000000001adc31c00d59634a566ee091ea0d41986d1b6bd15fdd0 height=941879 peer=17452 peeraddr=<redacted>
2026-03-23T15:43:24Z UpdateTip: new best=00000000000000000001adc31c00d59634a566ee091ea0d41986d1b6bd15fdd0 height=941879 version=0x25a0a000 log2_work=96.137363 tx=1326992798 date='2026-03-23T15:43:07Z' progress=1.000000 cache=254.8MiB(1883291txo)
2026-03-23T15:48:17Z Saw new header hash=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 peer=16953 peeraddr=<redacted>
2026-03-23T15:48:17Z UpdateTip: new best=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 version=0x2d2b0000 log2_work=96.137372 tx=1326996390 date='2026-03-23T15:48:05Z' progress=1.000000 cache=254.8MiB(1889060txo)
2026-03-23T15:49:54Z Saw new cmpctblock header hash=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 peer=13205 peeraddr=<redacted>
2026-03-23T15:49:54Z UpdateTip: new best=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 version=0x3092c000 log2_work=96.137382 tx=1327000957 date='2026-03-23T15:49:35Z' progress=1.000000 cache=255.3MiB(1894096txo)
2026-03-23T15:51:47Z Saw new cmpctblock header hash=00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e height=941882 peer=6013 peeraddr=<redacted>
2026-03-23T15:51:47Z UpdateTip: new best=00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e height=941882 version=0x2008c000 log2_work=96.137391 tx=1327001829 date='2026-03-23T15:51:19Z' progress=1.000000 cache=255.5MiB(1895308txo)
2026-03-23T15:55:09Z Saw new header hash=000000000000000000009c9acd0bc3207fa181f79f8573bf27d8a81d1ef3aa8e height=941883 peer=17690 peeraddr=<redacted>
2026-03-23T15:55:53Z UpdateTip: new best=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 version=0x3092c000 log2_work=96.137382 tx=1327000957 date='2026-03-23T15:49:35Z' progress=0.999995 cache=255.5MiB(1894755txo)
2026-03-23T15:55:53Z UpdateTip: new best=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 version=0x2d2b0000 log2_work=96.137372 tx=1326996390 date='2026-03-23T15:48:05Z' progress=0.999993 cache=255.5MiB(1889919txo)
2026-03-23T15:55:53Z UpdateTip: new best=00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 height=941881 version=0x22cd4000 log2_work=96.137382 tx=1327000861 date='2026-03-23T15:49:47Z' progress=0.999995 cache=255.5MiB(1894782txo)
2026-03-23T15:55:53Z UpdateTip: new best=00000000000000000000724eac69a18c6699c9f7aaab24bcf18beb2723ccadd2 height=941882 version=0x3427e000 log2_work=96.137391 tx=1327005400 date='2026-03-23T15:51:25Z' progress=0.999998 cache=256.0MiB(1898768txo)
2026-03-23T15:55:53Z UpdateTip: new best=000000000000000000009c9acd0bc3207fa181f79f8573bf27d8a81d1ef3aa8e height=941883 version=0x2fc2e000 log2_work=96.137401 tx=1327009788 date='2026-03-23T15:54:49Z' progress=1.000000 cache=256.5MiB(1903171txo)
2026-03-23T16:02:31Z Saw new header hash=0000000000000000000085ebdcd669c404195dbfeccbee902fc646dadc367a20 height=941884 peer=17420 peeraddr=<redacted>
2026-03-23T16:02:31Z UpdateTip: new best=0000000000000000000085ebdcd669c404195dbfeccbee902fc646dadc367a20 height=941884 version=0x212b4000 log2_work=96.137410 tx=1327013793 date='2026-03-23T16:02:14Z' progress=1.000000 cache=257.0MiB(1908016txo)
2026-03-23T16:04:49Z Saw new cmpctblock header hash=00000000000000000001f8562235e11fc74d5eea589e4c37b671b4213e89f52f height=941885 peer=17690 peeraddr=<redacted>
2026-03-23T16:04:49Z UpdateTip: new best=00000000000000000001f8562235e11fc74d5eea589e4c37b671b4213e89f52f height=941885 version=0x22abe000 log2_work=96.137420 tx=1327018030 date='2026-03-23T16:04:46Z' progress=1.000000 cache=257.5MiB(1911691txo)

A deeper time analysis is available here: https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/13?u=b10c

This looks a lot like intentional selfish-mining by Foundry USA to me (and others). My intention is not really to bash Foundry USA. I find it more interesting from the perspective why they chose to risk to outcompete Antpool and ViaBTC and go for a race to win block 941883 and better also 941884 to secure their own replacement blocks 941881 and 941882.

They ended up mining seven blocks in a row: 941879...941885. They took the risk and they won the race. Well, not everybody is amused, especially Antpool and ViaBTC obviously.

Sources: https://bnoc.xyz/t/two-block-reorg-at-height-941880/97?u=b10c

I have not yet an opinion. I've some mining experience from a long time ago, but I'm clearly no expert, especially regarding "modern mining". What's your opinion? It could've gone wrong for Foundry, no?

[_act_]

This looks a lot like intentional selfish-mining by Foundry USA to me (and others). My intention is not really to bash Foundry USA. I find it more interesting from the perspective why they chose to risk to outcompete Antpool and ViaBTC and go for a race to win block 941883 and better also 941884 to secure their own replacement blocks 941881 and 941882.

They ended up mining seven blocks in a row: 941879...941885. They took the risk and they won the race. Well, not everybody is amused, especially Antpool and ViaBTC obviously.

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.

[philipma1957]

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.

[DaveF]

It's also part of the issue I have pointed out here from the last time there was an issue with Foundry:

Taking it a bit past what was said above.
IF they are doing it properly and that is a big IF a large pool is running several nodes all over the world, when a block comes in they all should start validating it. Once a certain percentage of them agree then and only then do they start building the new block for the pool.

Loosing the fees even now is better then building a invalid block that gets rejected.
AND not broadcasting an empty block as soon as possible risks loosing it too.

It just comes down to routing. It takes about 1/2 a second to send 1 packet of data around the world without doing any kind of firewall / security inspection in an ideal setting.
Allowing for the nodes to verify what is in the block, and sending it back out is another couple of seconds and then start building a new block. If all is ideal you should have a new block ready to go in 10 seconds or so.

BUT, if you are waiting for minimum of 3 of 5 to do their thing you might add a few seconds on top of that.

Add in a bloated memory pool and some DPI From firewalls and you add a few seconds again.

All of a sudden you are looking at more time to build a block.

Even now there are 2 schools of thought with what happened with what happened with foundry the other day.
Some people including Kano are saying that they tried to orphan a couple of blocks.
Others are saying that they saw foundrys blocks 1st.

It has always been the way it works.

And part of the problem is that even if you understand BTC perfectly, unless you understand the true issues of internet routing and the true delays that proper DPI can put into network performance then it's never going to seem logical as to what happened.

Dave's pool can put it's nodes out there in public.
A corporation with all kinds of security requirements probably has 3 layers of security devices looking at all data coming in before it even hits the node to be processed. Dave's node has seen, and processed the block before it has even gotten through the security devices of some places. On the flip side, it's a lot harder to take out big corps node(s) by flooding them with bad data since it never even makes it into the network.


-Dave

* DPI = deep packet inspection. https://www.fortinet.com/resources/cyberglossary/dpi-deep-packet-inspection

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

[Cricktor]

I do not see this as selfishness.

I tend to disagree on this.

... that they didn't see the other blocks or the other blocks did not clear their security quick enough for some reason.

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.

[DaveF]

I do not see this as selfishness.

I tend to disagree on this.

... that they didn't see the other blocks or the other blocks did not clear their security quick enough for some reason.

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:

BUT, if you are waiting for minimum of 3 of 5 to do their thing you might add a few seconds on top of that.

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

[NotFuzzyWarm]

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.

[Cricktor]

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.

[NotFuzzyWarm]

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

[LoyceV]

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.

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.

Why wouldn't they mine on top of their own block if they have one?

But it shatters kind of my view of honest mining by established Bitcoin mining game theory.

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.

[VashaUdacha777]

I have not yet an opinion. I've some mining experience from a long time ago, but I'm clearly no expert, especially regarding "modern mining". What's your opinion? It could've gone wrong for Foundry, no?

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.

[Cricktor]

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 block.

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.