FTC Diff Change
-
[quote name=“jeremiel” post=“14331” timestamp=“1371154940”]
[quote author=erk link=topic=1741.msg14296#msg14296 date=1371151633]
The coin is safest from attack when the block rate is at it’s fastest. http://we.lovebitco.in/bitcoin-paper/#ch11The hash rate is irrelevant, it could be one PC mining and the block rate should still be 2.5min, however it’s the change in hash rate which is what we need to compensate for. The coin diff rate correction algorithm is designed to detect block creation velocity not acceleration, so is only works well when the hash rate is constant for long periods of time. Having a large base pool of miners is just a crude way of reducing hash rate acceleration/deceleration, thus working around the flaw in the diff correction algorithm. Reducing the sample period for the diff adjustment is also a workaround for the flaw in the diff correction algorithm, and in my opinion much cheaper and easier to achieve.
It’s now been several day since the last diff change and the Expected Time per Block has blown out to over 13min. [b]If FTC was being used by merchants for transactions there would be outrage[/b] If you have ever used Bitpay for BTC you would know that it gives you 15min to transfer your BTC, and BTC has a Expected Time per Block of 10min, so Bitpay gives you 50% room for error to complete the transfer. FTC Expected Time per Block is currently over 500% longer than intended, not just 50%, if it was on Bitpay all transactions would be failing.
[/quote]
Excuse me i’m a bit of un-informed on certain aspects so thus I ask questions to know more…
Just so we are on the same page, your idea is that a shorter block retarget period will achieve the 2.5 min mark. You also talk about acceleration rate being the real problem. Is a shorter block retarget the best option to solve acceleration/deceleration issues or are there other possibilities? And if the shorter block retarget is the solution what is the optimum span and how do you account for massive hash surges?
[/quote]I am going to drag in some calculus like I had talked about in my first post. Lets start off with the basics, the derivative of position is velocity, the derivative of velocity is acceleration. Lets apply this for a minute to the block chain, each completed block works exactly the same as a position, the network hashrate is our velocity, and the change in network hashrate is our acceleration. Currently diff retargets are based off the time it takes to complete the last x number of blocks. This like dividing up position locations into remansums and using this rough calculation to adjust the diff with a cap on how much it can change. Lets apply some calc 1 to this and get a much smoother picture of how the diff should be adjusted. As the remansum intervals for diff calculation approach 0 this would be the same as taking the derivative of position which is the current network hashrate . I am a bit groggy today from that long ass bruins game last night so there might be some errors in this.
The problems with this are instead of an equation we have a set of points that could be regressed to an approx equation that is changing on the fly as new information comes in and the data set grows. Now anyone who has taken calc knows that the smaller you slice the remansums (time interval) the closer we can get to the derivative without having to calculate it. Thus my proposal is cut the number of blocks to retarget down considerably and set a smaller cap on the % that the diff can change. This way when miners begin to join us we will retarget and adjust quicker and when they start leaving we will be able to retarget faster. Another example this can be compared to is compounding interest and the differences between yearly, monthly, weekly, and continually compounding interest.
My math these days is a bit rusty but I hope some of you can understand my suggestion.
As a side note in 3-4 weeks I should have free time again because ill be moved out of my current house and would love to join or help out the dev team.
-
[quote name=“Markus1337” post=“14350” timestamp=“1371157429”]
Number 4 from your list justabit stopped me :( but you have my backup zerodrama ;)
[/quote]Argue ideas, not each other is fairly straight forward to me.
-
While we welcome respectful discussion and debate, we will not tolerate personal attacks on any other member of the community.
You have been warned about this a number of times.
If you make another personal attack on any other member of the community, I will ban you, to avoid any accusations of unfairness to justabit.
Enough is enough.
Stefan
-
So I’ve not heard a good argument against just lowering the retarget rate. One suggestion was that it reduced the value of the coin, but I’ve not understood that argument. Would anyone care to elaborate why having retargets every 100 blocks with a 41.1% cap on change be bad?
-
Another option could be an AI run diff changing system where its looking at hashrate acceleration, block times, and market rates and based on prior data it will try to predict what the next diff will be before people even switch to it. This calculation could be run every minute and pumped out to the stats site for the next estimate. The best part is you can train and test this on live data as a proof of concept.
As a side note my favorite part of programming has and always will be computing algorithms of any kind :P I love math way too much to enjoy everything else as much that goes along with programming.
-
[quote name=“erk” post=“13848” timestamp=“1371073828”]
I feel the diff change speed is still way to slow. It should be at least half the number of blocks that it is now or less. ie. 252 not 504.We are leaving ourselves open to another fork attack by letting the confirmation time rise so much, plus it’s a major hurdle for doing meaningful commerce with the coin when confirms are 10min or more. I have been quite vocal about the slow diff re-targets for months now, and the recent attacks add weight to my concern.
The original diff target was set to instamine on launch, and has nothing to do with long term coin usefulness. If I was the dev I would set the re-target to 100 blocks as the 41.4% restriction, means your re-targets have much less effect than the original code base. A block re-target every 100 blocks is much easier to work out when the next re-target will, occur, you don’t have to remember when the last one was and add 504 to it, I see no downside.
The 504 block target is supposed to be 24hr when you multiply 504 x 2.5min, but that’s BS because in reality the block time is virtually never 2.5min, it’s higher or lower.
[/quote]You think it’s slow to drop because it went up faster than before and you couldn’t cash out. If we make it shorter, you’ll have even less time to profit and cash out. You think the difficulty will drop faster, but it won’t, because with the shorter profit times, more people will leave. Therefore it will take just as long for difficulty to drop.
Then the attacks will come which will drive the difficulty way higher than before because even though there’s a limit in rise, there’s a retarget every 30 minutes (100 blocks at ludicrous speed). Then the majority of the blocks will be found by the attacker so no one will want to mine. Once that happens, 100 blocks will take the same 7 - 20 days.
Before arguing about difficulty, google a parabola and stare at it until you understand that low extremes are just as bad as high extremes. Until you understand that low extremes in design result in the same exact situation as we had before, you will simply not get it.
-
[quote name=“RIPPEDDRAGON” post=“14363” timestamp=“1371158801”]
Another option could be an AI run diff changing system where its looking at hashrate acceleration, block times, and market rates and based on prior data it will try to predict what the next diff will be before people even switch to it.
[/quote]I had a very similar idea I shot over to Bush concerning prediction. What are the community thoughts on this one?
-
[quote name=“justabitoftime” post=“14370” timestamp=“1371159884”]
[quote author=RIPPEDDRAGON link=topic=1741.msg14363#msg14363 date=1371158801]
Another option could be an AI run diff changing system where its looking at hashrate acceleration, block times, and market rates and based on prior data it will try to predict what the next diff will be before people even switch to it.
[/quote]I had a very similar idea I shot over to Bush concerning prediction. What are the community thoughts on this one?
[/quote]A custom alg would be good to set FTC apart from the rest of the cryptos. I have done everything from breast cancer prediction, to finding water on meteors based on light returning from it, to building a bot that learned the best way to dodge based on its environment for unreal tournament. If you go the AI rout I would really like to help out with the development of this.
I also have a professor that is a friend of mine that works with bioinformatics and AI every day and if need be could be a great reference for this (if I asked her nicely lol).
-
[quote name=“justabitoftime” post=“14370” timestamp=“1371159884”]
[quote author=RIPPEDDRAGON link=topic=1741.msg14363#msg14363 date=1371158801]
Another option could be an AI run diff changing system where its looking at hashrate acceleration, block times, and market rates and based on prior data it will try to predict what the next diff will be before people even switch to it.
[/quote]I had a very similar idea I shot over to Bush concerning prediction. What are the community thoughts on this one?
[/quote]I don’t think market rates can exactly be placed in the equation. Who do you pull from and can this be a new attack vector?
-
[quote name=“justabitoftime” post=“14370” timestamp=“1371159884”]
[quote author=RIPPEDDRAGON link=topic=1741.msg14363#msg14363 date=1371158801]
Another option could be an AI run diff changing system where its looking at hashrate acceleration, block times, and market rates and based on prior data it will try to predict what the next diff will be before people even switch to it.
[/quote]I had a very similar idea I shot over to Bush concerning prediction. What are the community thoughts on this one?
[/quote]I actually like his earlier option with the approximation equation.
However, any change may end up being unnecessary. We now have double the hashrate than last time at the same difficulty and at same profitability. Sooner rather than later I think we will have enough dedicated hash to remain in a low difficulty range. In the medium run, our hash may fluctuate more than Litecoin, but we have a faster retarget.
We have to remember the current high difficulty is due to an unintended consequence of the attack which made the difficulty drop sending the profitability through the roof. I feel we will achieve decent stability as early as within 3-4 days.
-
With a few more diff changes behind us I would like to see some more input. How is everyone feeling about how the diff has been changing recently?
-
[quote name=“RIPPEDDRAGON” post=“16189” timestamp=“1371570709”]
With a few more diff changes behind us I would like to see some more input. How is everyone feeling about how the diff has been changing recently?
[/quote]Fine with me, the blocks are getting crunched and munched which is the important thing.
-
The purpose of a long diff retarget is to allow profit without immediate new investment, especially if there’s a sudden influx. Our proplem was the hit and run.
The closer an algorithm matches the difficulty to the hashrate, the less profit there is in providing the service.
It’s simple really. The hash rate moves up and down in a curve. The shorter the retarget, the more the algorithm hugs the curve. The more the algorithm hugs the curve, the less incentive there is to add hashing power.
And we know what low hashing power means:
51% attacks
long confirmations
difficulty traps
nearly zero inertia against pump and dumpIf we retarget too slow we wait forever to come out of difficulty traps.
If we retarget too fast we get more difficulty traps.If you want to have the right intuition about these dynamics, don’t think ramp (low = good / high = bad). Think parabola (extreme low, perfect middle, extreme high = bad, medium low/high/periodic change = good).
-
[quote name=“zerodrama” post=“16219” timestamp=“1371577099”]
The purpose of a long diff retarget is to allow profit without immediate new investment, especially if there’s a sudden influx. Our proplem was the hit and run.The closer an algorithm matches the difficulty to the hashrate, the less profit there is in providing the service.
[/quote]I 100% disagree with this statement. Profitability is based on the current market value of a coin and its difficulty. With our current system we will continue to yo-yo from most profitable to completely pointless. With this yo-yo we will continue to go from fast transactions to much slower ones as well offering a very inconsistent experience for merchants trying to use our system. With these profit swings we will see more pump and dump behavior with people trying to make as much as they can in a short period rather than holding and investing.
If a coin becomes less profitable people will always move away from mining it. This will always result in a lower diff which will increase profitability until it hits equilibrium. If you adjust quicker you will lower the length of high profit but also bring the low profit periods down. You will have a much more stable block time and much more stable profitability. Trying to find an equilibrium with huge 41% swings is like trying to do Acid-Base Titrations by dumping Acids and Bases (up to 41% of your mixture volume) into your solution until you get it stable.
-
[quote name=“RIPPEDDRAGON” post=“16232” timestamp=“1371581174”]If a coin becomes less profitable people will always move away from mining it.[/quote]
Not always and not all. I admit there are people who cannot foresee tomorrow and make their choices according to whatever DustCoin or CoinChoose display. They always jump from one pool to another and so on, also from one crypto to another and so forth. Let them be, no crypto can be top profitable all the time. What we need for now is market expansion and hash rate high enough to sustain block generation rate at least within Bitcoin’s 10 minutes.
-
[quote name=“ghostlander” post=“16243” timestamp=“1371582750”]What we need for now is market expansion and hash rate high enough to sustain block generation rate at least within Bitcoin’s 10 minutes.
[/quote]And we’re still comfortably within that bound at least.
-
[quote name=“ghostlander” post=“16243” timestamp=“1371582750”]
[quote author=RIPPEDDRAGON link=topic=1741.msg16232#msg16232 date=1371581174]If a coin becomes less profitable people will always move away from mining it.[/quote]Not always and not all. I admit there are people who cannot foresee tomorrow and make their choices according to whatever DustCoin or CoinChoose display. They always jump from one pool to another and so on, also from one crypto to another and so forth. Let them be, no crypto can be top profitable all the time. What we need for now is market expansion and hash rate high enough to sustain block generation rate at least within Bitcoin’s 10 minutes.
[/quote]In general this will hold true for a majority of the population. This was taken out of context just read the next sentence. If I had used the words ALL people will move away then you would have a point. Some people, like me, will stick it out regardless.
-
[quote name=“RIPPEDDRAGON” post=“16232” timestamp=“1371581174”]
[quote author=zerodrama link=topic=1741.msg16219#msg16219 date=1371577099]
The purpose of a long diff retarget is to allow profit without immediate new investment, especially if there’s a sudden influx. Our proplem was the hit and run.The closer an algorithm matches the difficulty to the hashrate, the less profit there is in providing the service.
[/quote]If you have a faster retarget, your recent upgrade of mining equipment becomes worthless faster because you end up getting the same result that you did two weeks ago when you bought it.
You do not want to hug the curve.
-
[quote name=“zerodrama” post=“16253” timestamp=“1371584033”]
[quote author=zerodrama link=topic=1741.msg16219#msg16219 date=1371577099]
The purpose of a long diff retarget is to allow profit without immediate new investment, especially if there’s a sudden influx. Our proplem was the hit and run.The closer an algorithm matches the difficulty to the hashrate, the less profit there is in providing the service.
[/quote]If you have a faster retarget, your recent upgrade of mining equipment becomes worthless faster because you end up getting the same result that you did two weeks ago when you bought it.
You do not want to hug the curve.
[/quote]What evidence do you have to back up such broad claims? The same can happen with long diff changes it does not matter how close you hug the curve. If FTC market value jumps for any reason and makes it the most profitable miners will swap over until its not the most profitable. Then your diff skyrockets and the value falls a bit. All a sudden your equipment becomes worthless mining FTC till the diff drops again. The only thing that makes your mining equipment worth less is more people buying mining equipment causing the global hash rate across all cryptos to rise.
A .004 pump and dump could crush FTC for weeks again because our hash rate will skyrocket. I know I mined through one but if it happens again I will not be able to afford to continue to do it. You hurt loyal miners and help hoppers a lot by letting the diff jump like it does now. If you want to reward consistent mining you need to hug the hash rate with your diff more.
-
I also disagree with the profitability and long retarget. what we need is a stable time per block, the bitcoin algo is based on one curency having up and down from start and stop of mining not to flavor of the day big switch. Alt coins are in a different scenario as switch is a factor. so up difficulty also brings less hash power and lower more hash power. so the retarget formula that only take into account the block time should be extend to take the hash change into account.
this in fact is not simple as it has an external factor the price that can’t easily be inlcude without bringing error. but a factor .25 to .75 in the retarget should do a nice trick. the overall max is the same but the move is just slower. let say we retarget by 40% at .5 we do a 20%. so if the calculation get 88% we should get max at 41.4%.
do the point is .25 .4 .5 .6 .66 .75 is difficult to determine. but i personally think .5 is a good guess as hash rate variation seems to be inversely proportional to the difficulty in a nearly linear way. the actual retarget is over 100% so would get a 41.4% (as the LTC retarget to lower diff soon after we retarget with higher diff give us a dive in profitability and then hash rate). this formula should have retarget us at around 134 instead of 144.
for sure external event like retarget of BTC and LTC and other alt coins has effect and can’t be account for so .25 is probably not enough responsive. a big drop in price can also makes the hash rate change, but the profitability is already compute in the hash rate. non profitable = less hash rate, more profitable = more hash rate and hash rate is measure via the time per block at current difficulty. so the block time actually used already takes into account all external factor it is just not as linear as it should be with a single coin with the alt coins profitability switch.
note: We can get a small value added to use a small weighting to calculate the time per bloc favoring the recent block. so we get a better idea from event that happen lately. but this should be marginal as overweighting them can lead to retarget attack.
