On Monday, Foundry made some waves by finding seven blocks in a row (#1459566). But, perhaps just as startling was the two-block reorg that happened at the beginning of Foundry's lucky streak (#1459137).
Two block reorgs aren't very common. The last one before this seems to have been 788686 -- which curiously enough, it looks like Foundry was on the losing side of to Ant Pool.
However, Jason Hughes from OCEAN Mining noted some odd things about the two block reorg from earlier this week:
⁉️ None of the nodes I run or have access to ever saw Foundry blocks or headers for 941881 or 941882 until after 941883 was mined and came through... including nodes peered directly with some known Foundry-controlled nodes.
⁉️ No DATUM miner on OCEAN ever built work on top of either Foundry block 941881 or 941882 (around a thousand globally diverse nodes).
Hughes noted that DATUM miners all run their own nodes and that there are somewhere around 1000 DATUM miners mining with OCEAN. When splits happen, Hughes says there is usually some percent of DATUM miners who see each side of the split. However, Hughes says yesterday's split was different:
not a single DATUM miner was building on either of the two eventually-winning Foundry blocks at 941881 or 941882. From my POV, there was zero indication of a race happening until Antpool and ViaBTC's blocks were proofed out of the chain.
So, I guess this sounds a lot like Foundry was selfish mining, which may be an attack or an optimization, depending on how you see it.
Whatever you think about selfish mining, Jason Hughes also points out that Monday's two-block reorg is pretty much what an attempt to censor out a certain transaction would look like:
this is actually what a 51% attack targeting removal of a couple of blocks could actually look like. Generally you wouldn't need to give a public indication of success or attempt until you were successful. That's what seemed to happen here if viewed in a bit of a vacuum. (I'm not saying this was an attack, just that this is what one would look like.)
Important to know you really don't need 51% to pull off a few blocks of reorg consistently. For example, Foundry has more than enough centralized hash rate to have a _very_ high chance of success if they were to do something like this intentionally.
It's worth noting though that had this been such an attempt, the hypothetically censored transaction still probably could have gotten through in an hour or two, when some other miner found a block -- especially if the hypothetically censored transaction bumped its fees.
b10c posted a salient update to this one on bnoc.xyz:
https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/19
Nodes will retrieve and store competing chaintips with the same amount of POW, when they are offered, but they will only propagate their best chaintip to peers. So a second competing block would not be forwarded. It would therefore be expected for competing blocks to propagate less widely than uncontested blocks.
Foundry’s first block was timestamped 12s after the Antpool block and Foundry’s second block was timestamped six seconds after ViaBTC’s block. Timestamps do not have to be super accurate, but looking at Foundry’s recent blocks, those seem to be pretty accurate to the actual time (some miners time-roll, but it might be the case Foundry does not—I’d have to look more into it to confidently say so).
However, if the timestamps are accurate, it is possible that Foundry found both of those blocks just after the competing blocks were found, before they had learned about the competing blocks, but after their block would have propagated widely on the network.
I got some timestamps for a miner mining at Foundry's pool:
https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/20
It indeed seems to be the case that they mined these two blocks just after the competing ones.
But that still seems like a very big coincidence for noone else to have seen the block in time. The direct peers of Foundry should have still seen it when it was found. But so far I haven't seen anyone claiming to have seen the Foundry block 941882 before 15:55:00.
It could perhaps even be the case that the block was found by a pool participant even after Foundry saw the Antpool block, but before they had updated all the jobs. It would still make sense and not be malicious for a pool to mine on their own block when they have one.
Wow you might be right. It seems this is what actually happened.
https://bnoc.xyz/t/two-block-reorg-at-height-941880/97/20
What a massive coincidence though.
Could be.
But even in this scenario I believe the usual
bitcoindbehaviour is to broadcast this block out to its direct peers.As I mentioned above, Bitcoin Core nodes will request and store blocks in competing chaintips with the same PoW as their best chaintip, but they will not announce those blocks to their own peers. Even if Foundry had announced it after having found it, the block could have not made it beyond the Foundry nodes’ peers if they all had seen the competing block before it, or it would have possible made it another hope from a few peers before getting blackholed.
*or it would have possibly made it another hop from a few peers before getting blackholed.
FTFM
Thanks for these details. So, it's not a huge leap to say that it was mostly a coincidence that some nodes didn't see Foundry's blocks until after the reorganization?
I think that it is plausible, yeah. And if we’re honest, Bitcoiners tend to entertain conspiracy theories perhaps a little to enthusiastically.
Even if this wasn't intentional by Foundry, it wouldn't change the fact that they benefited from this and AntPool+ViaBTC lost their reward. (Accidental Selfish Mining) And this was only possible because they already control so much hash rate.
yes. that is certainly a trait of this community.
How does Ocean know what blocks Datum miners see and build on? I thought Datum was decentralized...As time goes on these people at Ocean who mislead people about the architecture of their pool will be exposed for the liars they are.
Its not a coincidence that these same exact people are pushing BIP110 and misleading people about spam and relay policy.
🤦♂️
Obviously they know which block a miner builds on, because they submit their shares to the pool. Nothing weird about that.
So all miners are submitting their shares to a centralized pool operator.
Hence why its not decentralized.
The block templates are constructed by each individual miner.
That doesn't make Ocean decentralized. Ocean has can reject the template or shares you submit to their pool server. The state can easily target Ocean and mandate conditions on what temaplates/shares they accept. This is what we call a central point of failure.
Yes they could.
But they cannot stop a miner from broadcasting a valid block.
Any interventions imposed on Ocean would be enforced before any block is found. Like any centralized pool, condition can be put on the operators before anyone is even allowed to join the pool, let alone mine a block.
I disagree that this is connected to the filter debate. The conversation about miner centralization, while connected to some of the technical basis of the filter debate, is pretty distinct. I don't think the tribalism helps here.
I am just pointing out that the people at Ocean have no problem misleading people for their own gain.
The strange thing is, BitMEX Research claims to have seen the Foundry block 941881 at 15:50:08 already.
https://forkmonitor.info/stale/941881
Which gives us this timeline:
Still notice the 3+ minute gap between 941882 ViaBTC and 941882 Foundry.
Source: #1459279
it better not be selfish mining via block withodling, or so help me.
If block witholding is profitable, why wouldn't a miner with a lot of hash rate do it? It's not like we should expect miners to be altruistic.
By that logic, you'd be fine with a mining pool having 51% of the hashrate.
No, but I am not surprised when miners try to increase their hash rate. Nor do I expect them to selflessly abstain from gaining "too much."
I expect that miners will do what they can to gain an edge. If we cannot prevent selfish mining, why should we expect miners to abstain from it?
I suppose there is an argument to be made that miners ought to avoid selfish mining because it is bad for the long term health of the network.
However, imagine this scenario: there is a miner with 30% of the hashrate. Then there are two or three pools who combined maybe come up to 25%. If the pools were to band together and selfish mine in order to try to gain an edge on the larger single miner, it might be a good thing.
it's a declaration of war that spirals into applying zero sum games to all the edge cases, fee sniping, 33% miner attacks etc.
we should strive to avoid these bad faith antics for as long as possible, socially.
100%
And mining needs to be more decentralized. A single Stratum v1 pool controlling 33% of hash is a problem.
That's what it looks like though.
this table would be nicer with a column for block hash
that way all blocks would be uniquely identified. block hash is an id, height isn't
Here you go:
I saw the same but I restarted my big node a couple hours prior and it takes a while to get proper incoming again. It does mean that something was going on tho. However, @Filiprogrammer didn't see it coming in in a string according to his logs - why publish early?
Need a more reliable source than the theories of a known set of BIP-110 scorched earth pushers.
I don't know that I would call all of OCEAN "BIP-110 scorched earth pushers." Jason Hughes is not someone I have followed too closely, but he hasn't been too voluble on the filter debate of late.
(If you search his profile for the term "spam" he does express some pretty pro knots opinions in 2025, but it's still not on a "scorched earth" level.
He constantly lies about Ocean/Datum being permissionless and decentralized pool mining though.
Fair enough. So let's exclude that angle. Why though is Mr. Hughes trying to set a narrative that one of their competitors is doing 51% attacks?
Ocean only have around 1% of the hash rate right? So it shouldn't be surprising that any DATUM miners see this happening.
This has nothing to do with the hash rate. It's a lot of nodes distributed around the globe. And none of them saw the Foundry block, which is weird.
I don't know. I don't actually think hash rate is relevant here because it's a question of block propagation. We could just as well ask this question of a network of node runners who haven't got any hash rate at all. The question is, if there are 1000 nodes that make 10 (12 really) connections, is it surprising that none of those 12,000 (1000 nodes x 10 connected nodes) heard about these blocks.
Could be the fact that the majority of people mining on Ocean are running Knots with heavy relay policy, which we know slows block validation and propagation.
Maybe, but it's not just OCEAN miners who didn't see the Foundry block 941882. I have so far not seen anyone who claims to have seen this block before 15:55:00. Also all the mining pools listed on https://stratum.work/ didn't see it either.
deleted by author
https://twiiit.com/wk057/status/2036674054971703361