The re-design of the Bitcoin block header

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
Advertisements

, , ,

  1. #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…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: