Difficulty Technicalities: Please Stand By While We Solve The Wrong Problem
-
It’s really difficult to separate “are we there yet?” posts from technical details, so here I go.
I have seen a few different solutions offered. Two stand out: the difficulty limiter seems interesting and the 9 block filter.
Somehow in the shock of this difficulty slump, we’ve forgotten what difficulty is supposed to do. Difficulty attempts to guarantee that no more and no less than a given transaction rate happens. Having a regular reward and difficulty rate allows people make abstract decisions about business and personal goals instead of checking the rates every so often just to maintain a base level of profit and opportunity. *cough* Terracoin, you fiend! *cough* Difficulty also makes 51% attacks harder.
Second, the more I have thought about it I realize we are proof that this difficulty rise in Bitcoin IS A PROBLEM. It’s just that no one expects the network to switch to a new model. Not yet, anyway. But it’s not really the fact that difficulty is high. But rather that the Bitcoin system as used by FTC and BTC and other crypotcoins does not react to acceleration, only velocity.
The 9 block filter does not address the structural issues only the near term system behavior. It will adjust to regular difficulty jumps, but it will not handle the splitting of the bitcoin market into people who have the big guns and people who are running to new pastures.
We have a stampede coming. That filter is going to be abused because it is based on the idea that difficulty is bad. No. Difficulty is good, strip mining a coin to death is bad. Low difficulty = more strip mining.
-
If you scare off your miners with no rewards you have no miners.
If you scare off your spectators with no coins (or not enough new ones) you have no buyers or sellers.
If you have no buyers or sellers, all you really have is a bunch of numbers with no value.
The difficulty needs to be challenging, not impossible, and currently, with a 21 day lead time and a difficulty and profitability index MUCH lower than that of the bitcoin ecosystem (which is the standard, and has miners, and buyers, and sellers, AND merchants) the system will collapse.
Two solutions. Find a way to drastically increase the value of the coin OR change the difficulty, to whatever it needs to be, NOW.
-
A very interesting post
-
[quote name=“randomdef” post=“2873” timestamp=“1368394747”]
If you scare off your miners with no rewards you have no miners.If you scare off your spectators with no coins (or not enough new ones) you have no buyers or sellers.
If you have no buyers or sellers, all you really have is a bunch of numbers with no value.
The difficulty needs to be challenging, not impossible, and currently, with a 21 day lead time and a difficulty and profitability index MUCH lower than that of the bitcoin ecosystem (which is the standard, and has miners, and buyers, and sellers, AND merchants) the system will collapse.
Two solutions. Find a way to drastically increase the value of the coin OR change the difficulty, to whatever it needs to be, NOW.
[/quote]If the difficulty moves too fast you will have people buying and dumping like crazy. I already have choice number one figured out.
-
Ahems.
So here comes the algorithm:
Assume we are at a 2016 block boundary.
H[sub]0[/sub] = the average hashrate over the last 2016 blocks.
R[sub]y,x[/sub] = the ratio between two average hashrates, H[sub]y[/sub] / H[sub]x[/sub].
D[sub]0[/sub] = the classical difficulty using H[sub]0[/sub].R[sub]0,0[/sub] = 1.
1. When we arrive at block 504 of the new round:
H[sub]1[/sub] = the average hashrate of the last 2016 blocks (from original blocks 504 to 2519 according to the last round).So, D[sub]1[/sub] = D[sub]0[/sub] * (R[sub]0,0[/sub] + R[sub]1,0[/sub]) / 2
2. At block 1008 of the new round:
H[sub]2[/sub] = the average hashrate of the last 2016 blocks (from original blocks 1008 to 3023 according to the last round).
H[sub]3[/sub] = the projected hashrate ahead of H[sub]2[/sub] by two iterations, given the last two readings.
H[sub]3[/sub] = H[sub]0[/sub] * ((R[sub]1,0[/sub] + R[sub]2,1[/sub]) / 2)[sup]3[/sup]So, D[sub]2[/sub] = D[sub]0[/sub] * (R[sub]1,0[/sub] + R[sub]3,0[/sub]) / 2
3. When we are at block 1512, we may have evidence of a tendency becoming a trend. However, since we are averaging the predicted hashrate should still be close enough.
H[sub]4[/sub] = the average hashrate of the last 2016 blocks (from original blocks 1512 to 3527 according to the last round).
H[sub]5[/sub] = the initial hashrate multiplied by the average ratio of the last three readings applied over three iterations.
H[sub]6[/sub] = the projected hashrate ahead of H[sub]5[/sub] by two iterations.H[sub]5[/sub] = H[sub]0[/sub] * ((R[sub]1,0[/sub] + R[sub]2,1[/sub] + R[sub]4,2[/sub]) / 3)[sup]3[/sup]
H[sub]6[/sub] = H[sub]0[/sub] * ((R[sub]1,0[/sub] + R[sub]2,1[/sub] + R[sub]4,2[/sub]) / 3)[sup]5[/sup]So, D[sub]3[/sub] = D[sub]0[/sub] * (R[sub]5,0[/sub] + R[sub]6,0[/sub]) / 2
4. When we are at block 2016, the trend may become a set track.
H[sub]7[/sub] = the average hashrate of the last 2016 blocks (from original blocks 2016 (our block 0) to 4031 according to the last round).
H[sub]8[/sub] = the initial hashrate multiplied by the average ratio of the last four readings applied over five iterations.
H[sub]9[/sub] = the projected hashrate ahead of H[sub]8[/sub] by one iterations.H[sub]8[/sub] = H[sub]0[/sub] * ((R[sub]1,0[/sub] + R[sub]2,1[/sub] + R[sub]4,2[/sub] + R[sub]7,4[/sub]) / 4)[sup]5[/sup]
H[sub]9[/sub] = H[sub]0[/sub] * ((R[sub]1,0[/sub] + R[sub]2,1[/sub] + R[sub]4,2[/sub] + R[sub]7,4[/sub]) / 4)[sup]6[/sup]So, D[sub]4[/sub] = D[sub]0[/sub] * (R[sub]8,0[/sub] + R[sub]9,0[/sub]) / 2
I have run this on paper through several scenarios and it catches up to ramps and drops right after the second quarter round (504 blocks each).
The third and fourth quarter rounds cannot be used to profit from stripmining a currency and then leaving it limp like happened with several alts.
It also increases the cost of a 51% attack which may be attempted at a loss in hopes of maliciously destroying the blockchain or for profit.Attacks by both anti-alt trolls and thieves are made more difficult to carry out. In our situation, the stampeding GPUs coming from BTC are
going to have to come in more slowly or go to other alts or be sold. We just set the standard with this change. It may even be picked up by the
bitcoin developers.The standard difficulty parameter only tracks velocity of hashes not acceleration. Ours tracks and anticipates both. This solution also does not
have the inflationary bias of Freicoin and other alts which are loose with the money supply. The limit is there for a reason. The difficulty is
there for a reason. We are just adapting to a live situation.PWNT. @Bushstar, I can do a simple demo in C, which can take a CSV of hashrates so you can see it in action. But I think it’s fairly clear.
-
= 42
-
Interesting stuff :)
-
Although the whole concept of hash rate prediction is interesting, it needs more research. I’ve also noticed you’re not using geometric weighing which does improve prediction quality. Instead of calculating average hash rate over the past 2016 blocks, it’s better to do that for the each set of 504 blocks, then apply weights like 0.5, 0.25, 0.15, 0.10 from the newest to oldest of 4. Deeper averaging is also possible, though not really necessary. The rest of algorithm may be left unchanged, though certain limits may also be useful if calculated properly. Such approach allows difficulty to react fast enough to maintain given transaction rate yet makes attacks or other large hash rate variances more tolerable.
-
I’m trying to jump ahead of difficulty so that once the algo “detects” a trend, it chokes the extreme diffs at the 3rd and 4th quarter round. I’m not trying to predict the exact difficulty, but rather “head 'em off at the pass”.
Also I did originally try a geometric version, but it would require 2 diffferent sets of weights for increasing and decreasing trends, and then what do you do about the zigzags which can seem level but may actually be extreme, and the weights were all over the place depending on the simulated trend. The averages get better with each new quarter round input.
We could do 504 instead of 2016, but then we would have to sample it every 126 blocks.
In summary, the algorithm sacrifices perfect transaction rate to chase off wham bam thank you ma’am miners. It takes a bite out of the tx rate at times, and sometimes loosens up.
My approach goes like this:
First input, we assume equal chance of staying at the same hashrate or returning to the previous value.
Second input, we may go back one or forward one.
Third input, we may stay or we may skip one forward.
Fourth input, holy crap things are a bit hot! We’re going to hit the next one and maybe the next one after that.So we assume the worst ramp or drop (defined as consistent multiplier for each 504 averaged over 2016). Then we use that as a template and plug in the actual values. The result is that it stalks quietly when things are going well, and leaps at an attack or flood fairly quickly.
