0

The concept involves the first round of SHAKE256 generating a hash of dynamic length (ranging from 256 to 512 bits). The length is determined based on certain parameters, such as a combination of nonce and timestamp.

As an example, let's consider a blockchain system. In this context:

  1. In the first round of SHAKE256, specific fields from the block header (e.g., nonce, timestamp) are extracted, processed, and used to determine the dynamic length of the output hash.
  2. Instead of relying on the number of leading zeroes, as in traditional Proof-of-Work systems, the difficulty depends on the size of the hash, which varies within the range of 256 to 512 bits.
  3. The second round of SHAKE256 normalizes the output of the first round into a fixed-size hash (e.g., 256 bits) to maintain compatibility with the existing blockchain structures.

The question is as follows:

  1. What are the pros and cons of such a structure?
  2. What potential security issues could arise?
Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
blockchainman
  • 33
  • 3

1 Answers1

0

Disclaimer, not an expert on blockchain.

Let's start with the pros and cons of such a structure, going through the system part by part.

In the first round of SHAKE256, specific fields from the block header (e.g., nonce, timestamp) are extracted, processed, and used to determine the dynamic length of the output hash.

One problem I see is that although the result depends on the input, and the input does depend on time and the number of previous hashes. However, it doesn't allow for tweaking or setting it in case the time is going to take too long or big jumps in mining. That said, this could also be considered a pro in the sense that it doesn't depend on an organization to determine such values.

Instead of relying on the number of leading zeroes, as in traditional Proof-of-Work systems, the difficulty depends on the size of the hash, which varies within the range of 256 to 512 bits.

The size of the hash isn't a great work factor as it will take very little processing power and lots of memory. Basically if you rely on that the price of the hash will rely on memory or SSD prices alone.

The second round of SHAKE256 normalizes the output of the first round into a fixed-size hash (e.g., 256 bits) to maintain compatibility with the existing blockchain structures.

I hope you do understand that this second hash completely negates the first hash when it comes to size. You can run these two hashes in parallel (even in the same thread) and immediately feed the input of the first hash into the second.

That just means that you now have a hash that operates on $2 \cdot x$ iterations where one $x$ is the amount of blocks that need to be processed for the output hash to be generated and $x$ is of course the second hash that processed input blocks (not taking any possible overhead into account).

As for security concerns, I don't think there are many. This is not much different as the double SHA-256 used for e.g. BitCoin after all, even if that wasn't the intention.

One should take in account though that many systems do not optimize the Keccak sponge used internally, and that such systems could be created relatively simply - I know that hardware accelerators have been developed, they are just not used much yet.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323