pull down to refresh
0 sats \ 0 replies \ @0xB10C 15 Apr \ on: Bitcoin Mining Centralization in 2025 (by b10c) bitcoin
Thanks for posting but I didn't even have the chance to post it here myself first.
Stratum jobs don’t contain the full list of transactions included in the block template. A miner only needs to construct a block header, which can be done without knowing the full template contents. Modern miners exhaust the 32-bit nonce in the block header quite fast and can then either update the timestamp in the header, roll the version a la overt ASICBoost, or change the so-called extranonce in the coinbase transaction, which causes the Merkle root to change. For this, miners need the coinbase transaction, information about the extranonce, and the Merkle branches to calculate a new Merkle root.
The list of Merkle branches in stratum jobs contains just the information required to calculate the Merkle root. To build the Merkle root, the coinbase transaction is hashes together with the first Merkle branch, the result is then hashed with the second Merkle branch, which is then again hashed with the third Merkle branch. The Merkle root is reached once all Merkle branches have been hashed together.
On the mempool.space/stratum page, each colored column is a merkle branch (marked in red in my image). Normally, these are hashes, but I've started to color them at some point to make it easier to distinguish them. Equal color in a column means equal hash means equal merkle tree branch. If all merkle tree branches are equal, then the block template is the same too. If the block template is frequently the same, you can assume that the pools are the same.
I link to, for example, https://ofac.treasury.gov/recent-actions/20231003 when discussing the first block. This itself links to https://home.treasury.gov/news/press-releases/jy1779
Earlier this year, I wrote about the mutated blocks ViaBTC is sending out: https://b10c.me/observations/10-viabtc-blocks-without-witness-data/
I think it's important to note that this is a pre-release in form of the first release canidate (thats what rc1 means). These binaries should be used to test the release, not necessarily for production deployments as they can still contain bugs.
Companies or projects relying on Bitcoin Core might want to update a part of their infrastructure to v28.0rc1 now (and other release candidates later) to be sure they are compatible with the release. The hope is that bugs and other problems are catched with the release candidates and not the final release!