https://.nsite.run playing around with nsite.run 🤓

💯

text copied from X (@wk057) as answer on 0xB10c post about the "Foundry fork" I'm unsure what exactly happened here with Foundry. @b10c 's post has the nitty gritty details... but I guess I can add some interesting points: ⁉️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). Now for some commentary... While the former point above is interesting in itself, it's certainly an incomplete picture. The latter point is quite intriguing, though, since this is NOT how other splits have shown up in that data to-date... and for a two-block split I'd have expected something quite noticeable. For background, DATUM miners all run their own nodes to generate their own mining templates from their own view of the network and mempool policies. During a race on the network between multiple blocks, generally some % of the DATUM miners will see different sides of the chain and work on it as they see it until the eventual convergence brings everyone back to the same block to build on. From the pool's perspective, this is all fine, since both chains are valid and contain all of the pool's blocks. With around a thousand unique nodes run by different miners around the world, this is to be expected and gives some insight into forks overall. This latest two block reorg was different, though, as 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 poofed out of the chain. I do see in @b10c 's data that some of his nodes eventually got headers for Foundry's first block after ViaBTC's block, which makes this even more interesting since I'd presumed headers would propagate pretty quickly. If some of his nodes saw it before 941883, that makes this even more of a mystery to me. A disturbing bit is that 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 one of the reasons solving mining (de)centralization is so important. A centralized pool with 30-40% of the network has a solid chance of being able to "unconfirm" transactions they don't like or want to censor, do double spends, etc. With miners working on decentralized templates using DATUM, this is basically impossible because there's no centralized control of transaction selection, even if 100% of the network were on the same DATUM pool. Anyway, I take this as a reminder that mining centralization is a problem we should keep working to fix. Let's keep Bitcoin permissionless and censorship resistant. Mine with DATUM.

https://x.com/i/status/2036674054971703361 any thoughts on this?