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.
05-27-2014:
The proposed header was edited based on discussions:
- 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) |
|---|---|---|---|---|---|
| 0 | 0 | Version | Block version number | You upgrade the software and it specifies a new version | 4 |
| 0 | 4 | HashChildHeader | 256-bit double hash of the child header | A new block comes in | 32 |
| 0 | 36 | ZeroPad | left for future use | Never | 28 |
| 1 | 0 | PrefixOfHashOfHeader0 | 4 byte prefix of hash of the first 64 bytes (including ZeroPad). Corresponds to the last 4 bytes of the old Merkleroot |
A new block comes in | 4 |
| 1 | 4 | Nonce2 | Corresponds to the least significant bytes of the old time field (it’s stored in little-endian) |
A hash is tried | 2 |
| 1 | 6 | PrefixOfHashOfHeader1 | .the following 4 bytes of the prefix of the hash of the first 64 bytes. (totaling 10 bytes) Corresponds to the 2 most significant bytes of the old time field and the old difficulty field. |
A new block comes in | 6 |
|
1 |
12 | Nonce | 32-bit number | A hash is tried (increments) | 4 |
The child header is as follows:
| 64-Bytesub-block | Offset in sub-block | Field | Purpose | Updated when… | Size (Bytes) |
|---|---|---|---|---|---|
| 0 | 0 | Version | Child Block version number | You upgrade the software and it specifies a new version | 4 |
| 0 | 4 | hashPrevBlock | 256-bit hash of the previous block header | A new block comes in | 32 |
| 0 | 36 | hashMerkleRoot0 | 256-bit hash based on all of the transactions in the block (First 28 bytes) | A transaction is accepted | 28 |
| 1 | 0 | hashMerkleRoot1 | 256-bit hash based on all of the transactions in the block (Last 4 bytes) | A transaction is accepted | 4 |
| 1 | 4 | Time | Current timestamp as seconds since 1970-01-01T00:00 UTC | Every few seconds | 8 |
| 1 | 12 | Bits | Current target in compact format | The difficulty is adjusted | 4 |
Bitslog 
#1 by AB on April 1, 2014 - 5:58 pm
Do you think this:
http://www.reddit.com/r/Bitcoin/comments/20y0nq/why_do_all_the_blocks_hashed_by_unknown_miners/
could be related to the vulnerability you mention?
#2 by SDLerner on April 2, 2014 - 1:48 pm
🙂 sometimes 5 years can pass very quickly…