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.
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.
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.
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.
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, exampleExempli 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.
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.
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.
- the “third knob” ^