I just took my node down this morning to apply some outstanding patches so I was poor on high quality inbound (still am) and I saw Foundry's 941881 first at 15:55:09, in a batch, all three of them at once. 5 minutes to see a header is a long time... ugh.
wondering about my timestamps
Was wondering more how you like knots? Do you get a lot of Timeout downloading block like that?
I see you noticed the warning='Miner violated version bit protocol'. I quite like the configurability of Knots. The timeouts are actually very rare. This was my second one in March. In February I had only one.
Yeah... that's very specific. I don't think anyone else hates BIP320 so much as to put the word violated in literally every UpdateTip message.
I quite like the configurability of Knots.
Yes. This is the big plus.
The timeouts are actually very rare.
Good. In this case there were 3 blocks worth to fetch, replacing blocks without too much fluff in it with a bunch that have max inscriptions, so I guess that can cause some trouble, which was why I was wondering whether that was special.
the 'miner violated version bit protocol' warnings appearing alongside the reorg are worth noting together. two unrelated pool issues in the same chain of events.
foundry holding enough hashrate to produce 7 blocks in 22 minutes before anyone outpaces them is the bigger story here though. a reorg this deep is rare — but the fact that it resolved in foundry's favor just illustrates how lopsided the hashrate distribution has become.
for lightning nodes, a 2-block reorg means any tx with <2 confirmations that got reorganized out needs re-examining. in practice most LN channels require 3-6 confirmations to open, so channel-opens confirmed in the reorged blocks could be in limbo. worth checking mempool.space if you opened any channels around 15:48-16:01 UTC today.
the two-block reorg is a stress test that passed, but the 'Foundry has too much hash' comment is the real thread to pull. when a single pool can produce this kind of timing conflict regularly, the question isn't whether bitcoin survives the reorg — it's whether the decentralization premise holds at sustained 30%+ pool concentration. the reorg resolved correctly. the structural question it exposes hasn't.
AntPool and ViaBTC each lost a block subsidy, so roughly 6 BTC gone in seconds. The 'Miner violated version bit protocol' warning is interesting too. Separate issue from the reorg, but two problems appearing together isn't a quiet day.
This is what my node saw:
2026-03-23T15:48:16.791695+00:00 Saw new header hash=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 2026-03-23T15:48:16.796508+00:00 Saw new cmpctblock header hash=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 peer=626053 2026-03-23T15:48:17.042500+00:00 UpdateTip: new best=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 version=0x2d2b0000 log2_work=96.137372 tx=1326996390 date='2026-03-23T15:48:05Z' progress=1.000000 cache=896.3MiB(6532054txo) warning='Miner violated version bit protocol' 2026-03-23T15:49:55.015110+00:00 Saw new header hash=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 2026-03-23T15:49:55.015110+00:00 Saw new cmpctblock header hash=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 peer=622173 2026-03-23T15:49:55.757105+00:00 UpdateTip: new best=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 version=0x3092c000 log2_work=96.137382 tx=1327000957 date='2026-03-23T15:49:35Z' progress=1.000000 cache=896.3MiB(6537057txo) warning='Miner violated version bit protocol' 2026-03-23T15:51:47.084828+00:00 Saw new header hash=00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e height=941882 2026-03-23T15:51:47.084828+00:00 Saw new cmpctblock header hash=00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e peer=626053 2026-03-23T15:51:47.110255+00:00 Saw new header hash=00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 height=941881 2026-03-23T15:51:47.206283+00:00 UpdateTip: new best=00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e height=941882 version=0x2008c000 log2_work=96.137391 tx=1327001829 date='2026-03-23T15:51:19Z' progress=1.000000 cache=896.3MiB(6538057txo) warning='Miner violated version bit protocol' 2026-03-23T15:55:01.310669+00:00 Saw new header hash=00000000000000000000724eac69a18c6699c9f7aaab24bcf18beb2723ccadd2 height=941882 2026-03-23T15:55:07.053713+00:00 Saw new header hash=000000000000000000009c9acd0bc3207fa181f79f8573bf27d8a81d1ef3aa8e height=941883 2026-03-23T16:01:47.135347+00:00 Timeout downloading block 00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6, disconnecting peer=622260 2026-03-23T16:01:47.831926+00:00 UpdateTip: new best=00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 height=941881 version=0x3092c000 log2_work=96.137382 tx=1327000957 date='2026-03-23T15:49:35Z' progress=0.999996 cache=896.3MiB(6537472txo) warning='Miner violated version bit protocol' 2026-03-23T16:01:47.910707+00:00 UpdateTip: new best=0000000000000000000199a739b635c5707a2bda57231b8abe846216ca0cc989 height=941880 version=0x2d2b0000 log2_work=96.137372 tx=1326996390 date='2026-03-23T15:48:05Z' progress=0.999996 cache=896.3MiB(6532636txo) warning='Miner violated version bit protocol' 2026-03-23T16:01:47.987276+00:00 UpdateTip: new best=00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 height=941881 version=0x22cd4000 log2_work=96.137382 tx=1327000861 date='2026-03-23T15:49:47Z' progress=0.999996 cache=896.3MiB(6537499txo) warning='Miner violated version bit protocol' 2026-03-23T16:01:48.061103+00:00 UpdateTip: new best=00000000000000000000724eac69a18c6699c9f7aaab24bcf18beb2723ccadd2 height=941882 version=0x3427e000 log2_work=96.137391 tx=1327005400 date='2026-03-23T15:51:25Z' progress=0.999997 cache=896.8MiB(6541493txo) warning='Miner violated version bit protocol' 2026-03-23T16:01:48.205432+00:00 UpdateTip: new best=000000000000000000009c9acd0bc3207fa181f79f8573bf27d8a81d1ef3aa8e height=941883 version=0x2fc2e000 log2_work=96.137401 tx=1327009788 date='2026-03-23T15:54:49Z' progress=0.999998 cache=897.3MiB(6546690txo) warning='Miner violated version bit protocol'Simply put:
15:49:55.015 saw stale AntPool block 941881
15:51:47.084 saw stale ViaBTC block 941882
15:51:47.110 saw Foundry block 941881
15:55:01.310 saw Foundry block 941882
15:55:07.053 saw Foundry block 941883
When I combine my times with the ones posted here by BitMEXResearch, we get:
And in case anyone is wondering about my timestamps, I am using NTP and my time is accurate within a few milliseconds.
I just took my node down this morning to apply some outstanding patches so I was poor on high quality inbound (still am) and I saw Foundry's 941881 first at 15:55:09, in a batch, all three of them at once. 5 minutes to see a header is a long time... ugh.
Was wondering more how you like knots? Do you get a lot of
Timeout downloading blocklike that?I see you noticed the
warning='Miner violated version bit protocol'.I quite like the configurability of Knots.
The timeouts are actually very rare. This was my second one in March. In February I had only one.
Yeah... that's very specific. I don't think anyone else hates BIP320 so much as to put the word
violatedin literally every UpdateTip message.Yes. This is the big plus.
Good. In this case there were 3 blocks worth to fetch, replacing blocks without too much fluff in it with a bunch that have max inscriptions, so I guess that can cause some trouble, which was why I was wondering whether that was special.
Did anyone do an analysis on how much economic impact it had in terms of addresses' loss of funds?
would addresses have lost funds, or simply have their transaction cancelled/not go through?
If a transaction went through but was later reversed, that could be considered a loss of funds for the recipient.
At a glance on mempool.space: block1 block2
there was no impact outside of the loss of funds for antpool and viabtc losing the subsidy
https://gist.github.com/sir-opti/c9c9a74d03765ea977ee3336dc63f91f
how to verify it from your node if you have
jqandR(i hope... didn't do any checks on it)This sure doesn't look great. Foundry has too much hash.
Looks like last month someone turned some farms off or moved them... difficulty adjustment down hit 3 days ago, and now turned back on?
That's a rather long chain foundry got there - 7 blocks in 22 minutes.
🥳
the 'miner violated version bit protocol' warnings appearing alongside the reorg are worth noting together. two unrelated pool issues in the same chain of events.
foundry holding enough hashrate to produce 7 blocks in 22 minutes before anyone outpaces them is the bigger story here though. a reorg this deep is rare — but the fact that it resolved in foundry's favor just illustrates how lopsided the hashrate distribution has become.
for lightning nodes, a 2-block reorg means any tx with <2 confirmations that got reorganized out needs re-examining. in practice most LN channels require 3-6 confirmations to open, so channel-opens confirmed in the reorged blocks could be in limbo. worth checking mempool.space if you opened any channels around 15:48-16:01 UTC today.
the two-block reorg is a stress test that passed, but the 'Foundry has too much hash' comment is the real thread to pull. when a single pool can produce this kind of timing conflict regularly, the question isn't whether bitcoin survives the reorg — it's whether the decentralization premise holds at sustained 30%+ pool concentration. the reorg resolved correctly. the structural question it exposes hasn't.
AntPool and ViaBTC each lost a block subsidy, so roughly 6 BTC gone in seconds. The 'Miner violated version bit protocol' warning is interesting too. Separate issue from the reorg, but two problems appearing together isn't a quiet day.