Moore's law has almost come to a halt in our typical computing devices. By "typical" I mean based on silicon and non-reversible synchronous computing. Reversible computing might achieve a lot more, but it is a suspect idea due to quantum-based dispersion of precision in moving forward and backwards. Switching to something like carbon nanotubes could extend the limits, but those and any other material will still have limits based on causes like those below. Asynchronous computing has no limit, but breaking tasks up into parts for disparate computing has fundamental problems. On the other hand, brains are mostly asynchronous and capable.

The computing limit for irreversible synchronous non-quantum silicon computing is based on:

1) A logic device requires a certain minimum number of atoms.

2) Heat per bit change is released in irreversible computing, aka Landauer's principle, Q = T*k*ln(2). There may be a way around this. This does not change the basic limit in entropy cost that will ultimately come at an energy cost, but it might be capable of computing without a local increase in heat.

3) Probability of error increases as the energy we use to store or transmit a bit gets near Landauer's limit. I think the probability of error per computation or transmission is based on e^(-E/Q) where E is the energy per bit used to transmit or store the bit and Q is Landauer's limit. A modest 100 M transistor 3 GHz device would have an error every hour if E is 40x Q.

4) The speed of light is limited.

5) Atoms break apart if they get too hot.

6) The amount of heat a cold sink can extract out of a computing device is limited, even if it is only 1-layer thick.

In order for transistors to change state in step with each other, the distance across the chip is limited by the speed of light and the processor speed. The faster the processor, the smaller the chip has to be. For example, if the longest trace from the clock input to a remote transistor is 4x the chip die diameter and every transistor has to acquire the needed state in 1/4 a clock cycle, then the max diameter at 3 GHz owing to speed of light is 3E8 m/s / 3 GHz / 4 / 4 = 6 mm. This is approximately what is seen in current chips. Since the number of transistors increases as diameter squared, and the available size limit due to speed of light increases linearly with decreases in speed, more synchronous computing can be done with slower chip speeds. This also reduces the heat problem so that more layers of transistors can be used. This is why chip speed is not increasing. To take advantage of this (if we wnet to a slower speed), going to more channels (128 and higher instead of 64 bit) or more cores would be needed. More cores is currently the method that takes advantage of the largest die diameter allowed by the speed of light. A 3 MHz chip could do 1,000x more computing at a cost of 1,000,000x more transistors. It would not need to be 6 meters per side as this implies because it needs to dissipate 1,000x less energy per second which means it could be more layers thick.

Based on the speed of light, the above was pretty good at predicting current chip diameter. Now I'll try to predict chips speeds based on Landauer's limit. I explained energy usage per bit needs to be at least 40x Q to have 50% chance of error every hour. It only needs to be 50x to increase that to 1 error every 100,000 hours. I'll assume in practice it is currently 100x. I see a 14 nm AMD Ryzen 7 1800X chip has 4.8 billion transistors (14 mm per side) and uses a max of 95 Watts. This is not an intel chip, but intel says a 14 nm die has a max of 105 C. I'll guess transistors actually reach about 150 C locally. It's 4 GHz. I'll guess the average transistor changes state only 1/4 the time (once per 4 clock cycles). So, 100x Landauer's limit times the number of transistors times the clock speed divided by 4 = 100*(150+273 kelvins)*1.38E-23*ln(2)*4.8E9*4E9/4 = 2 watts. Actually, if every transistor needs to be able to not an error in 100,000 hours with my 2x energy safety/inefficiency factor, then the 1/4 maybe should not be applied., giving 8 watts in a weird adjusted basis. They seem to be wasting 95/8 = 12x more energy than the limit of what they could. The limit here seems to be chip temperature. They've made it as fast as they could without "melting". They've made the dies as big as they could for that speed. Smaller chip processes allow a squared factor (or more) of less energy usage while allowing a squared factor of more chips per die of the same size. So they can continue to make them smaller at the same speed and the heat profile will not change. The 50x limit implies they could go SQRT(12) = 3.5x smaller with my 100x estimate of a hard limit. That would be down to 14/3.5 = 4 nm. This is far from the limit based on heat dissipation. My assumptions could have made it 1 nm. I see 5 nm is scheduled for about 2020. Since atoms are only 0.2 nm wide, that must be getting close to the size limit before they have to resort to slower processor speeds to enable larger dies (or more layers).

# Evolution, thinking machines, economics, physics

## Friday, January 26, 2018

## Sunday, January 21, 2018

### Compressing short texts

I want to compress text to 512 bytes as much asp ossible for Zcash and Hush memo field.

I didn't have any luck searching the internet on how to compress short texts....until I had finished doing it from scratch. Normal compression algorithms are not useful because they need to include various types of look-up tables in the data which can make small texts even bigger.

I used Huffman-like look-up tables for the language at hand, using the known frequency of letters and words to make decisions, combined with other tricks based on knowing things like a capital letter will probably be a period. I used 2 bits to tell the decoder how many bits were about to follow depending on which table contained the word or letter to replace. 4, 6, 7, or 12 bits followed the 2 bits. The 4 bit table was for the 16 most common characters (e,t,a,i,o,l,s,n, newline, period, comma, from memory). The 12 bit table was for less-common words. I had a table of 4096 words. A 6 bit table was for the rest of ascii-printable characters, and the 7-bit was for the most common words.

But here's a better job of it in precise detail:

https://academic.oup.com/comjnl/article-pdf/24/4/324/1039097/240324.pdf

He and I got about compression down to about 45% of the original english files. He did it with only 250 words instead of 4096, so his method is really good. We're using almost exactly the same scheme, but he used only 4 bits for the most common letters which is why he was able to do as good with a lot less. It's hard to get better no matter how big the tables are, but my next improvement could be to follow his method exactly, but add another table for 4096 words with 12 bits after the 4-bit.

His method has a big additional advantage: by the bits staying multiple of 4, a common procedure can be applied: Burrow-Wheeler transform (BWT) followed by move-to-front (MTF), then Arithmetic encoding (AC). BWT gets like-symbols closer together which enables MTF to more frequently assign a low-number position number. BWT and MTF do not do compression. AC does the compression following MTF to make use of the lower entropy due to more frequent position numbers. By itself, the BWT-MTF-AC method got the original file down to 60% using 4 bit sequences. It did not benefit my method because my odd-length method offsets the bits all the time, making 4-bit sequences more random. 4-bit sequences are better instead of byte for short messages because AC has to attach a "dictionary" to the data (i.e. a list of each symbol's count in the original) and 4 bits means I need only 16 counts up 256 if no symbol is more than 25% of a 1000 byte pre-compression text (since my goal is 512 bytes and I won't get more than 50% on text already pre-compressed). That means only 16 extra bytes needed verses 256 for 8-bits (I'll just list the count in a logical order of fixed length instead of including both symbol and count). MTF will be a little longer since the ranking on 1000 bytes will require a distance of up to 2000 for 4-bits instead of 1000.

The 4-bit method is also immediately applicable to UTF-8.

I didn't have any luck searching the internet on how to compress short texts....until I had finished doing it from scratch. Normal compression algorithms are not useful because they need to include various types of look-up tables in the data which can make small texts even bigger.

I used Huffman-like look-up tables for the language at hand, using the known frequency of letters and words to make decisions, combined with other tricks based on knowing things like a capital letter will probably be a period. I used 2 bits to tell the decoder how many bits were about to follow depending on which table contained the word or letter to replace. 4, 6, 7, or 12 bits followed the 2 bits. The 4 bit table was for the 16 most common characters (e,t,a,i,o,l,s,n,

But here's a better job of it in precise detail:

https://academic.oup.com/comjnl/article-pdf/24/4/324/1039097/240324.pdf

He and I got about compression down to about 45% of the original english files. He did it with only 250 words instead of 4096, so his method is really good. We're using almost exactly the same scheme, but he used only 4 bits for the most common letters which is why he was able to do as good with a lot less. It's hard to get better no matter how big the tables are, but my next improvement could be to follow his method exactly, but add another table for 4096 words with 12 bits after the 4-bit.

His method has a big additional advantage: by the bits staying multiple of 4, a common procedure can be applied: Burrow-Wheeler transform (BWT) followed by move-to-front (MTF), then Arithmetic encoding (AC). BWT gets like-symbols closer together which enables MTF to more frequently assign a low-number position number. BWT and MTF do not do compression. AC does the compression following MTF to make use of the lower entropy due to more frequent position numbers. By itself, the BWT-MTF-AC method got the original file down to 60% using 4 bit sequences. It did not benefit my method because my odd-length method offsets the bits all the time, making 4-bit sequences more random. 4-bit sequences are better instead of byte for short messages because AC has to attach a "dictionary" to the data (i.e. a list of each symbol's count in the original) and 4 bits means I need only 16 counts up 256 if no symbol is more than 25% of a 1000 byte pre-compression text (since my goal is 512 bytes and I won't get more than 50% on text already pre-compressed). That means only 16 extra bytes needed verses 256 for 8-bits (I'll just list the count in a logical order of fixed length instead of including both symbol and count). MTF will be a little longer since the ranking on 1000 bytes will require a distance of up to 2000 for 4-bits instead of 1000.

The 4-bit method is also immediately applicable to UTF-8.

## Wednesday, December 27, 2017

### Using difficulty to get constant-value dev fees

I posted this to bitcoin-ml and bitcoin-dev mailists and to reddit and bitcointalk, but no one seems interested.

========

Has anyone used difficulty to get constant-dollar developer or node

fees? Difficulty is exactly proportional to network hashrate, and

network hashrate is closely proportional to coin price.

Say a coin is currently $1.23 and someone wants to get a fixed income

from the coin like $0.01 each time something occurs. To achieve this

they could use a constant that is multiplied by the difficulty:

fee = 0.0123 / difficultyat$1.23_per_coin * current_difficulty =~ $0.01

Dollar value here is constant-value relative to when the ratio was

determined (when difficulty was at $1.23). If hash power is not able

to keep up with coin price (which is a temporary effect), the value

would be larger than expected. Otherwise, the real-world value slowly

decreases as hashing efficiency increases, which may be a desired

effect if it is for dev fees because software gets outdated. But

Moore's law has gotten very slow for computers. Hashing should get

closer to being a constant hardware cost per hash.

Also, electricity is more than half the current cost of hashing and

could soon be 3/4 or more of the cost. Worldwide electricity cost is

very stable and possibly the best single-commodity measure of constant

value.

========

Has anyone used difficulty to get constant-dollar developer or node

fees? Difficulty is exactly proportional to network hashrate, and

network hashrate is closely proportional to coin price.

Say a coin is currently $1.23 and someone wants to get a fixed income

from the coin like $0.01 each time something occurs. To achieve this

they could use a constant that is multiplied by the difficulty:

fee = 0.0123 / difficultyat$1.23_per_coin * current_difficulty =~ $0.01

Dollar value here is constant-value relative to when the ratio was

determined (when difficulty was at $1.23). If hash power is not able

to keep up with coin price (which is a temporary effect), the value

would be larger than expected. Otherwise, the real-world value slowly

decreases as hashing efficiency increases, which may be a desired

effect if it is for dev fees because software gets outdated. But

Moore's law has gotten very slow for computers. Hashing should get

closer to being a constant hardware cost per hash.

Also, electricity is more than half the current cost of hashing and

could soon be 3/4 or more of the cost. Worldwide electricity cost is

very stable and possibly the best single-commodity measure of constant

value.

## Tuesday, November 21, 2017

### Best difficulty algorithm

I'm changing this as I find improvements. Last change: 12/1/2017.

Newest information is here:

https://github.com/zawy12/difficulty-algorithms/issues/1

This first one appears to be the best all around:

In an simple average (SMA), a multiplicative error like this only causes a proportional error in solvetime, not a compounded error.

There is a T/solvetime ratio in two places. It must be the same in both places. I don't know how it would be coded to give something different, but it's something to be aware of.

==========

The following attempts to make it smoother while having some ability to respond to faster to big hashrate changes.

Newest information is here:

https://github.com/zawy12/difficulty-algorithms/issues/1

This first one appears to be the best all around:

# Jacob Eliosoff's EMA (exponential moving average) # https://en.wikipedia.org/wiki/Moving_average#Application_to_measuring_computer_performance # ST = solvetime, T=target solvetime # height = most recently solved block # N=70 # MTP should not be used for (i=height - 10 to height) { # check timestamps starting 10 blocks into past) previous_max = max max=timestamp[i] if timestamp[i] > max } ST = max - previous_max ST = max(T/100,min(T*10, ST)) next_D = previous_D * ( T/ST + e^(-ST/T/N) * (1-T/ST) )A word of caution with the above EMA: when converting to and from bits field (aka target) to difficulty, it is important to not make a consistently wrong "rounding" error. For example, if previous difficulty was 100,000, it is important that nothing in the code make it consistently +50 more or consistently -50 less (0.05% error). That would cause the EMA at N=70 to have 3.5% error in solvetime. At 0.5% error per block, there is 35% error in the solvetimes (difficulty is 30% too high or low). The error that develops seems to be based on about 1.005^70 = 41%. If half the time it is +1,000 too high and the other half -1,000 too low, then it's OK. just don't be consistently wrong in the same direction. Error in the value for e=2.7183 does not hurt it.

In an simple average (SMA), a multiplicative error like this only causes a proportional error in solvetime, not a compounded error.

There is a T/solvetime ratio in two places. It must be the same in both places. I don't know how it would be coded to give something different, but it's something to be aware of.

==========

The following attempts to make it smoother while having some ability to respond to faster to big hashrate changes.

# Dynamic EMA difficulty algo (Jacob Eliosoff's EMA and Zawy's adjustable window). # Bitcoin cash dev(?) came up with the median of three to reduce timestamp errors. # For EMA origins see # https://en.wikipedia.org/wiki/Moving_average#Application_to_measuring_computer_performance # "Dynamic" means it triggers to a faster-responding value for N if a substantial change in hashrate # is detected. It increases from that event back to Nmax Nmax=100 # max EMA window Nmin=25 # min EMA window A=10, B=2, C=0.37 # A,B,C = 10,2,37 or 20, 1.65 0.45, # TS=timestamp, T=target solvetime, i.e. 600 seconds # Find the most recent unusual 20-block event for (i=height-Nmax to height) { # height=current block index if ( (median(TS[i],TS[i-1],TS[i-2]) - median(TS[i-20],TS[i-21],TS[i-22]))/T/A > B or (median(TS[i],TS[i-1],TS[i-2]) - median(TS[i-20],TS[i-21],TS[i-22]))/T/A < C ) { unusual_event=height - i + Nmin } } N = min(Nmax, unusual_event)) # now do the EMA shown above with this NHere's another algorithm that seems to be about as good as the EMA

# Weighted-Weighted Harmonic Mean (WWHM) difficulty algorithm # Original idea from Tom Harding (Deger8) called "WT-144" # No limits, filtering, or tempering should be attempted. # MTP should not be used. # set constants # N=60 # See Masari coin for live data with N=60 # T=600 # coin's Target solvetime. If this changes, nothing else needs to be changed. # adjust=0.99 # 0.98 for N=30, 0.99 for N=60 # k = (N+1)/2 *adjust * T # there is not a missing N. # height = most recently solved block # algorithm d=0, t=0, j=0 previous_max=timestamp[height - N] for ( i = height-N+1; i < height+1; i++) { # (N most recent blocks) max_timestamp=max(timestamp[i], previous_max) solvetime = max_timestamp - previous_max solvetime=1 if solvetime < 1 # for N=60, 10*T solvetimes drives difficulty too far down, so: solvetime = 10*T if solvetime > 10*T previous_max=max_timestamp j++ t += solvetime * j d += D[i] # sum the difficulties this is how WWHM is different from Tom's WT. } t=T*N if t < T*N # in case of startup weirdness, keep t reasonable next_D = d * k / t # limits on next_D do not need to be used because of the above solvetime restrictions # but if you still want limits on D's change per block & expect max 5x hash rate # changes or want to replace the solvetime restrictions, use # limit = 5^(3/N) # next_D = previous_D*limit if next_D > previous_D*limit # next_D = previous_D/limit if next_D > previous_D/limit

## Monday, November 13, 2017

### Maximizing options as the basis of memory-less intelligence

There seems to be some big news in A.I. and cosmology. To give an example of how far-reaching this idea is, view walking upright and the ability to use our hands as something that maximizes our options rather than something that gives us more power in any other sense. This simple algorithm can successfully play games without any training at all, other than defining "maximize future options" for a given set of rules.

I am far from certain his general view is correct (or even expressed clearly enough to criticize. I still can't view it as anymore than a method of problem solving when his claims are much greater than that, but I can't exactly understand his claims. It sounds like he is saying things appear intelligent because nature somehow keeps options open.

Ted Talk

https://www.ted.com/talks/alex_wissner_gross_a_new_equation_for_intelligence

General idea:

https://physics.aps.org/articles/v6/46

How it's good at playing atari without training:

http://entropicai.blogspot.com/2017/06/solved-atari-games.html#more

On freedom in society making us more powerful:

https://www.edge.org/response-detail/26181

Basic physics of causal entropy and intelligence

http://www.alexwg.org/publications/PhysRevLett_110-168702.pdf

How it can predict the cosmological constant by following the anthropic principle:

http://www.slac.stanford.edu/cgi-wrap/getdoc/slac-pub-12353.pdf

I am far from certain his general view is correct (or even expressed clearly enough to criticize. I still can't view it as anymore than a method of problem solving when his claims are much greater than that, but I can't exactly understand his claims. It sounds like he is saying things appear intelligent because nature somehow keeps options open.

Ted Talk

https://www.ted.com/talks/alex_wissner_gross_a_new_equation_for_intelligence

General idea:

https://physics.aps.org/articles/v6/46

How it's good at playing atari without training:

http://entropicai.blogspot.com/2017/06/solved-atari-games.html#more

On freedom in society making us more powerful:

https://www.edge.org/response-detail/26181

Basic physics of causal entropy and intelligence

http://www.alexwg.org/publications/PhysRevLett_110-168702.pdf

How it can predict the cosmological constant by following the anthropic principle:

http://www.slac.stanford.edu/cgi-wrap/getdoc/slac-pub-12353.pdf

## Wednesday, November 1, 2017

### Why Degner8's WT difficulty algorithm is the best

I previously said difficulty is not open to debate or opinion. By this

I mean a scientific measurement should be followed by a mathematical

calculation. We should measure current hashrate and then

mathematically set difficulty based on that to get the desired average

solvetime. The only discussion (debate and opinion) needed is to

determine how to make the measurement and how to do the math. This

coincidentally provides the perfect protection to hash attacks and

delays (unless you change the Poisson by shifting consensus from POW

to better time restrictions set by the nodes, i.e. Andrew Stone's

idea.)

The difficulty math should be: difficulty = 600 * hashrate. Hashrate

= current difficulty / current solvetime. This part is not open for

debate. The problem is determining current hashrate because the only

way to measure it is to see the network response to current

difficulty, and it's current difficulty that we're looking for. (I

should mention schancel has an idea on how to get a true "current

hashrate", but as with long tail and block reward adjustment I

consider it "for the future"). So the best we can do is to base the

math on the hashrate on the previous difficulty. The problem is

random variation. What observations and math should we use to

estimate current hash rate? This is open for debate, but it's not

debatable in a sense because there should be some provable optimum.

With this background I want to "prove" Degnr8's WT with low N is the

optimal formula. Bitcoin measures avg hashrate of past 2 weeks of

blocks by using the perfectly correct next_D = sum (D) / sum(solvetimes)

times a proportionality constant. So it is measuring hashrate as it

was 1 week in the past, and only adjusts once every two weeks.

(Hashrate = difficulty times a proportionality constant)

Obviously this is not the best measure of current hashrate. So,

everyone started using the same equation, but applying it every block

and using a smaller N. There have been many attempts to improve this

math, but every attempt I am aware of made it worse. The amount of

time wasted trying to improvement it is incredible. They go by a lot

of fancy names. They often apply a "filter" to try to reduce the

"noise", but they don't understand that the random variation is not

real noise that has a forcing function that needs to be filtered out

with something analogous to a capacitor and/or inductor on an

electrical signal. It can be noisy from miners jumping on and off or

from network effects, but we have no way to estimate the nature of

that noise in order to justify a specific filter design. The random

variation is, as far as we can measure, precise data that needs to be

included. Devs will also hurt the incontrovertible math by making

asymmetrical changes such as preventing negative timestamps. They have

their reasoning processes, but their reasoning is not as good as the

required math.

The simple average with low N is the state of the art. But it

has a problem: it is measuring the hashrate as it was N/2 blocks into

the past. Lower N helps, but there starts to be accidental variation

that causes longer delays. Fear of this is greatly exaggerated.

Filters do not help because the end result is not as good as just

going to a longer N. Degnr8's algo does not address the tradeoff

between faster response and accidental changes in difficulty that

occurs with low N. But by letting the weighting factor for the blocks

linearly reduce as they get further in the past, he's made possibly

the best possible measurement of the hashrate as it stood in the

PREVIOUS block rather than looking at N/2. There might be a slightly

more complex equation to make it a little more accurate, but if it

overestimates what the previous, current, or future block hashrates

are, it will send it into oscillations by overshooting, leaving it

open to exploit that amplifies the oscillations. Industrial process

controllers (PID controllers) do something better, but they depend on

the process being stable in its characteristic, not something like

miners seeking profit and thereby able to change how they react to the

controller. In other words diff algos can't try to predict the future

hashrate. The best they can do is estimate what the hashrate was in

the previous block. In watching Degnr8's WT respond to step

functions, it is a very linear increase. This is the hallmark of a

controller that is NOT trying to predict the future. It responds

faster than the simple equation, but does not overshoot or undershoot

in any sense.

This is the basis for me claiming there is no alternative to using

Degnr8's TW. The only thing to quibble over is the setting of N. I'm

down for 30. I'm working on getting an exposition of what it looks

like when small alts use N=16, 30, and 63.

I mean a scientific measurement should be followed by a mathematical

calculation. We should measure current hashrate and then

mathematically set difficulty based on that to get the desired average

solvetime. The only discussion (debate and opinion) needed is to

determine how to make the measurement and how to do the math. This

coincidentally provides the perfect protection to hash attacks and

delays (unless you change the Poisson by shifting consensus from POW

to better time restrictions set by the nodes, i.e. Andrew Stone's

idea.)

The difficulty math should be: difficulty = 600 * hashrate. Hashrate

= current difficulty / current solvetime. This part is not open for

debate. The problem is determining current hashrate because the only

way to measure it is to see the network response to current

difficulty, and it's current difficulty that we're looking for. (I

should mention schancel has an idea on how to get a true "current

hashrate", but as with long tail and block reward adjustment I

consider it "for the future"). So the best we can do is to base the

math on the hashrate on the previous difficulty. The problem is

random variation. What observations and math should we use to

estimate current hash rate? This is open for debate, but it's not

debatable in a sense because there should be some provable optimum.

With this background I want to "prove" Degnr8's WT with low N is the

optimal formula. Bitcoin measures avg hashrate of past 2 weeks of

blocks by using the perfectly correct next_D = sum (D) / sum(solvetimes)

times a proportionality constant. So it is measuring hashrate as it

was 1 week in the past, and only adjusts once every two weeks.

(Hashrate = difficulty times a proportionality constant)

Obviously this is not the best measure of current hashrate. So,

everyone started using the same equation, but applying it every block

and using a smaller N. There have been many attempts to improve this

math, but every attempt I am aware of made it worse. The amount of

time wasted trying to improvement it is incredible. They go by a lot

of fancy names. They often apply a "filter" to try to reduce the

"noise", but they don't understand that the random variation is not

real noise that has a forcing function that needs to be filtered out

with something analogous to a capacitor and/or inductor on an

electrical signal. It can be noisy from miners jumping on and off or

from network effects, but we have no way to estimate the nature of

that noise in order to justify a specific filter design. The random

variation is, as far as we can measure, precise data that needs to be

included. Devs will also hurt the incontrovertible math by making

asymmetrical changes such as preventing negative timestamps. They have

their reasoning processes, but their reasoning is not as good as the

required math.

The simple average with low N is the state of the art. But it

has a problem: it is measuring the hashrate as it was N/2 blocks into

the past. Lower N helps, but there starts to be accidental variation

that causes longer delays. Fear of this is greatly exaggerated.

Filters do not help because the end result is not as good as just

going to a longer N. Degnr8's algo does not address the tradeoff

between faster response and accidental changes in difficulty that

occurs with low N. But by letting the weighting factor for the blocks

linearly reduce as they get further in the past, he's made possibly

the best possible measurement of the hashrate as it stood in the

PREVIOUS block rather than looking at N/2. There might be a slightly

more complex equation to make it a little more accurate, but if it

overestimates what the previous, current, or future block hashrates

are, it will send it into oscillations by overshooting, leaving it

open to exploit that amplifies the oscillations. Industrial process

controllers (PID controllers) do something better, but they depend on

the process being stable in its characteristic, not something like

miners seeking profit and thereby able to change how they react to the

controller. In other words diff algos can't try to predict the future

hashrate. The best they can do is estimate what the hashrate was in

the previous block. In watching Degnr8's WT respond to step

functions, it is a very linear increase. This is the hallmark of a

controller that is NOT trying to predict the future. It responds

faster than the simple equation, but does not overshoot or undershoot

in any sense.

This is the basis for me claiming there is no alternative to using

Degnr8's TW. The only thing to quibble over is the setting of N. I'm

down for 30. I'm working on getting an exposition of what it looks

like when small alts use N=16, 30, and 63.

## Saturday, October 21, 2017

### bits field relation to hashing and difficulty

In the block explorer you can see a "bits" field determines the difficulty that can be compared between all coins. It is a compact form of the maximum value the hash of the block header must have before nodes will accept the miner's hash. A miner's job is to hash until he can find a hash that is less than the hash value stated in the bits field. The difficulty algorithm sets the bits field value. In HUSH's block 190703 the bits field is 1d 08 ec fa. The 1d in decimal is 29, which means the max hash value is 29 bytes long. The 08 ec fa gives the value of the first 3 of those 29 bytes. The rest of them are 00. If you convert those 1st three to decimal and multiple that by 256^(29-3) it is 2.4E68. The hash of a block header is 32 bytes long, which can take on 2^32 = 1.15E77 different values. The miner's job is to keeping hashing, changing the nonce field between each hash (with a starting point given to him by the pool) to get a different hash each time, until he finds a 32 byte hash that is below that 2.4E68 number. 2.4E68 is 481 million tmies less than 1.16E77. So the miner has to hash that many times in 150 seconds to have a 50% chance of winning. 481 / 150 = 3.21 million hashes per second, which was the network hashrate during that block. The difficulty in hush-cli as you said was 239 M. 2^1 * 239 / 150 = 3.19 M Hashes/s network rate. For some reason, in Zcash replace the 2^1 with 2^13.

Subscribe to:
Posts (Atom)