Daniel P. Barron

The New Bitcoin

Thursday, March 17, 2016 

As per Shane’s request to put this information somewhere other than the log, I present to you a somewhat more organized summary of the changes proposed in order for The Most Serene Republic to have an implementation of bitcoin ready for the summer of forks.

Mircea reminds us:

ok. so currently, for every block being mined : a header is calculated ; to this a nonce is added, the combine hashed. the resultant hash has to be smaller than a number to qualify as a found block.

He makes a new proposal:

in the proposed model : a header is calculated, same way. to this, a nonce is added, the combine hashed. this is hash 1. a digest is calculated, on the basis of past blocks. to this, the SAME nonce is added. the combine hashed. this is hash 2
BOTH hash 1 and hash 2 have to be under a number to qualify as a found block.

Shane asks:

ok and this goes back to the discussion this am right? re: sha(header+nonce) AND sha(digest+nonce) ? or did i read that wrong?

Mircea responds:

it does. i specifically left the “hashing” undefined. it can be defined so both use sha3. or first stays as is and 2nd sha3. etc.
this is a twistable knob.

Juroj asks:

how is the digest from past blocks done?

Mircea responds:

out of every Nth preceding block, the nonce-th byte is put in a string ; the combine hashed.

N is another twistable knob. can be 1, can be whatever.
see footnote 2, example

Exempli gratia : if the fourth block is added to a blockchain consisting of

60 bd e7 67 77 70 20 b2 e6 7c 46 c3 (12 bytes)
75 80 d2 b0 6e 6c 6d a9 5d 12 98 fe bf (13 bytes)
df fc 22 5f 2a 4d 50 d6 f3 fc c3 (11 bytes)

Then should that block use a nonce of 17, it must include a field equal to sha3-512(70 6e 50), whereas should that block use a nonce of 11, it must include a field equal to sha3-512(c3 fe df).

and yet another twistable knob exists : the nonce may be shifted before taking the nonceth element.

knob 1 above decides whether to obsolete current miners entirely or just partially, and is a [true] soft vs hard fork ; knob 2 decides how much i/o pressure to put on relay nodes ; knob 3 decides how much relay work to require in the mix.

it’s not entirely impossible to make the shifting a function of difficulty differential (note that there isn’t a rule BOTH hashes have to be under THE SAME number. if there’s two numbers, you could have an equalizer algo that does the shift moving)
but, obviously – the more moving parts, the more problems.

Juroj challenges:

well then my comment still applies – miner can keep the nonce constant and churn hash1 by changing one transaction in a cycle

Mircea responds:

how ? his hash2 won’t change.

my modeling shows it’d be way cheaper to calculate nonce blocks than to try and churn merkel trees

now, your observation is correct in that this possibility puts a hard limit on how much miners can be raped.

but i don’t think SUCH hard rape is contemplated at all.

just… a little breather for nodes.

the thing is, currently nodes only need disk ; cpu is wasted. ideally a node should use both, so that it makes sense to keep boxes as relay nodes.

I ask:

how does this i relate to more or less “relay work” ?

Mircea responds:

if the nonce is not shifted at all, each digest is good for exactly one nonce. if the nonce is shifted one bit, each digest is good for 2 nonces. if it is shifted 10 bits, 1024 nonces. etc.

an important point to consider is the data & i/o meaning of “1 petahash”. if each single hash requires 256 bits of data to proceed, you are looking at 32 petabytes of data that has to move. in a second ? ouch.

let’s work an example. say the nonce is 7. this means hash1=f(header+7) and hash2 = g(digest(7)+7)

if in fact a shift by 2 was in effect, it’d be the case that hash1=f(header+7) and hash2 = g(digest(1)+1)

hash2 would have been the same for all nonces over 3, ie, 4, 5, 6 and 7. it’d have also been the same for all nonces under 4, ie, 0, 1, 2 and 3.

this means you get to do 4 old style hashings for each new style digest you calculate.

this because 2 bits = 22 = 4. had the shift been 17 bits, then you’d get to do 217 = 131072 old style hashings for each new style digest you calculate.

7 is 111 in binary. 0111 shifted 2 is 0001

Allow me to summarize, to the best of my understanding.

Knob 1

There are two hash functions. One is on the block header as is currently used, and the other is on the digest as per the new proposal.

Minimum setting

The existing function can be left the same as it is today, causing minimal harm to miners. The second function could also be the same, giving maximum benefit to said miners.

Middle setting

The digest hash could be derived instead from sha3, forcing miners to either invest in some new equipment, or rely in part on the work of other nodes. Or the digest could come from sha2 leaving something for existing miners to do.

Maximum setting

Both hashes could be set to sha3, trashing existing miners completely.

Knob 2

The digest hash is made from a string containing parts of preceding blocks. This second knob sets just how many of those blocks a node will have to dig up in order to create a valid string.

Minimum setting

There isn’t an exact minimum here, but it would be a very large number, close to the block height at the time.

Middle setting

There is a very wide range of clicks on this knob. Any integer from 1 to the block height. For example, setting this knob to 10 would require digest creators to dig up at least 40 thousand past blocks. Setting it to 100 would require 4 thousand. A setting of 1`000 would require 400 and so on..

Maximum setting

A setting of 1 would require a piece of every single past block. This would put a great deal on strain on digest creators.

Knob 3

This knob concerns the difference in difficulty between the two required hashes. It can be tuned to require more or less “old” style hashes for each “new” digest style.

Minimum setting

Although there is no strict lowest setting in this case, any large number would make it easier for existing miners to operate. The larger the shift, the more digest hashes will be a correct fit per old-style hash.

Middle setting

There exists the possibility of determining the shift value algorithmically based on the difference between hash difficulties, so as to balance the work between the two. If, for example, it becomes too difficult to calculate the digest hash, a larger shift may be used. Or if traditional mining is the more difficult, the shift may be reduced so that mining is hindered by the ability to produce digests. The value of the shift works exponentially so that a shift of 2 results in a 4-to-1 balance, and a shift of 17 results in a 131`072-to-1 balance.

Maximum setting

Like the previous knob, the maximum setting is simply 1. That means one digest hash is required for each header hash. Turning the knob to this end means an enormous amount of data has to move per second in order for a miner to mine.

  1. the “third knob” ^

Leave a Reply

Your criticism is welcome. Your name and website are optional. Some HTML tags are allowed.