Bitcoin BLAKE2B is really starting to get under way. They’ve published their first list of complete changes as part of their official splitting away from BTC.
They may be full of a bunch of nonsense, but they do have thousands of fanatical Bitcoiners working away with a fresh slate for innovation. Something something monkeys & typewriters. So I believe it is certainly in our best interest to monitor them casually (as with BTC, XEC, BSV, NEXA and other altcoins) because there may be gems in the mine to copy or iterate on. If I had to guess, their best stuff will probably come from mining tweaks, they have quite a lot of fanatical interest and experience in that sector.
At the very least, this is a good test case for what if WE had to do a PoW change because of overwhelming evidence that hijackers had total control of SHA256.
Here is their list of initial changes, as per Zender on Twitter and the Knots Github release. To me the only interesting looking one at first glance is the block header format changes. As I understand it, this is partially their fix for the 64 byte collisions issue that already has been fixed in BCH, but it’s also so they can address miner block withholding attacks and possibly some other stuff. So something for us to research and keep an eye on.
But I’m interested to see what others think of the list and I do want to have a thread where we can keep tabs on what they come up with.
BLAKE2b hardfork activated. Here are the changes:
Flag-day hard fork:
At block 961,640, the consensus rules change. SHA256d blocks become invalid from that height onward.BLAKE2b proof of work:
SHA256d mining is replaced with BLAKE2b. The initial target is shifted by 22 bits, equivalent to roughly 218 TH/s for 10-minute blocks.The existing 2,016-block difficulty-adjustment system remains unchanged.
- New block-header format:
Post-fork blocks use a mandatory 164-byte version-2 header instead of Bitcoin’s traditional 80-byte header.It adds the block height, transaction count, expanded nonce fields, ASIC profiles, time-offset data, an XOR key and a merge-mining field.
Transaction-count commitment:
The header directly commits to the number of transactions in the block. This addresses the Merkle-tree ambiguity behind CVE-2017-12842.Block-withholding mitigation:
Miners can optionally use a secret XOR key so workers cannot identify complete valid blocks and selectively withhold them.Unified sighash:
A new opt-in SIGHASH_UNIFIED format works across legacy, SegWit and Taproot inputs.It provides linear signature hashing, commits to every input amount and gives one-way replay protection.
Old signatures remain valid, so these protections only apply when the spender opts in.
Temporary RDTS rules:
From block 961,640 until the parent block’s median-time-past reaches 1 September 2027, blocks are limited to 800,000 weight units, approximately 300 kB.Temporary script restrictions:
During RDTS:
- Stack elements are limited to 256 bytes.
- Taproot trees are limited to seven levels.
- Taproot annexes are forbidden.
- OP_IF and OP_NOTIF are forbidden in Tapscript.
- Unknown witness and Taproot upgrade mechanisms are invalid.
- Inputs spending coins created before the fork are grandfathered.
Activation headline:
The first BLAKE2b block must contain a specific, externally configured news headline in its coinbase transaction.Future hooks:
The new header reserves infrastructure for merge-mined sidechains and 40-bit timestamps, but those features are not fully activated yet.