Bitcoin block
Today is the third time I find an attack to the way Bitcoin uses SHA-256 to perform mining. Two of the attacks belong to a new family of attacks that involve terribly technical details about the inner workings of SHA-256. These are attacks that may impact on Bitcoin probably not before 5 years, and they could even never have a real impact on Bitcoin. I will talk openly about them when I can really tell if they could affect Bitcoin. And if they can, better be prepared. The good news is that many of these attacks (at least the ones I identified) can be prevented by a hard-fork involving changing the block header without breaking compatibility with current mining ASICs. Since changing the block header requires a hard-fork, it’s free to add more nonce bytes, and so help future ASIC manufacturers to reach higher hashing rates. Also the time field could be increased to 8 bytes. The new design requires only 6 more bytes or storage in its compressed format, but mining requires the record to be expanded to fit three 64-byte blocks, instead of two.
- Time increased from UINT32 to UINT64
- Header is split between a master and a child to prevent breaking the SHA-2 spec.
- PrefixOfHashOfHeader split in two to leave the least significant bytes of time field as nonce for hardwares that use these bytes.
Here it is:
64-Bytesub-block | Offset in sub-block | Field | Purpose | Updated when… | Size (Bytes) |
---|---|---|---|---|---|
Version | Block version number | You upgrade the software and it specifies a new version | |||
HashChildHeader | 256-bit double hash of the child header | A new block comes in | 32 | ||
36 | ZeroPad | left for future use | Never | 28 | |
PrefixOfHashOfHeader0 | 4 byte prefix of hash of the first 64 bytes (including ZeroPad).
Corresponds to the last 4 bytes of the old Merkleroot | ||||
Nonce2 | Corresponds to the least significant bytes of the old time field (it’s stored in little-endian) |