pull down to refresh

I would add that another trade-off of Utreexo is that nodes need archive nodes to do IBD. There is a distinction in Utreexo that nodes that only store the set of hashes can't help other nodes bootstrap. They rely on at least some nodes storing the full chain.
You don't have to prune the chain to use Utreexo.
feeds luke jr spam paranoia (even though its bullshit)
Massive signatures make this problem even worse. They would make more use of the witness discount and thereby bloat blocks to 3-4 MB, thereby making it harder to run a node.
The aim has always been to scale Bitcoin while using as little space as possible (Segwit, Taproot, and hopefully CISA soon). I have no interest in crippling Bitcoin transaction throughput with massive signatures because some people like to spread FUD.
And here’s the kicker: Anthropic acquired Bun at the end of last year, and Claude Code is built on top of it. A Bun bug (oven-sh/bun#28001), filed on March 11, reports that source maps are served in production mode even though Bun’s own docs say they should be disabled. The issue is still open. If that’s what caused the leak, then Anthropic’s own toolchain shipped a known bug that exposed their own product’s source code.
lol, you can't make this up
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.
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.
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.
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.
Yes they could.
But they cannot stop a miner from broadcasting a valid block.
Could be.
But even in this scenario I believe the usual bitcoind behaviour is to broadcast this block out to its direct peers.
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.
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.
Here you go:
| First Seen | Height | Miner | Chain | Block-Hash |
| 15:49:54 | 941881 | AntPool | losing | 00000000000000000001b3ff8b13e57c3ec1eca3ba7d2937edbd9f219eb2d9f3 |
| 15:50:08 | 941881 | Foundry | winning | 00000000000000000000bd4930a5982911e7749eb491886206e71abdc1ec0cc6 |
| 15:51:47.084 | 941882 | ViaBTC | losing | 00000000000000000000c81cbf94a12ca498e72eb8530f7061c8746cf9687b2e |
| 15:55:01.310 | 941882 | Foundry | winning | 00000000000000000000724eac69a18c6699c9f7aaab24bcf18beb2723ccadd2 |
| 15:55:03 | 941883 | Foundry | winning | 000000000000000000009c9acd0bc3207fa181f79f8573bf27d8a81d1ef3aa8e |
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.
🤦♂️
Obviously they know which block a miner builds on, because they submit their shares to the pool. Nothing weird about that.
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.
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:
| First Seen | Height | Miner | Chain |
| 15:49:54 | 941881 | AntPool | losing |
| 15:50:08 | 941881 | Foundry | winning |
| 15:51:47.084 | 941882 | ViaBTC | losing |
| 15:55:01.310 | 941882 | Foundry | winning |
| 15:55:03 | 941883 | Foundry | winning |
Still notice the 3+ minute gap between 941882 ViaBTC and 941882 Foundry.
Source: #1459279
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.
That advantage is that you don't have to store the UTXO set. This could improve validation performance if you are RAM constrained, since you don't have to access the disk to load some part of the UTXO set you don't currently have cached in RAM.