[Dev] Hard fork to change retarget, averages and block time
-
We’ve completed the validation tests, but are keeping the test net going for the moment, as a soak in test. If possible it would be great if more members joined over today (Sunday). The main tests are done now if you need to stop testnet mining.
The plan is to keep the testnet going for the moment and it will be available to start testing the potential hashing algo changes, as soon as possible.
i.e. Yes and no,
Yes we are keeping it going, member test hash rate isn’t so essential after today (30th), unless something turns up and we want some retests. We would let you know…
-
I still minerd. :)
minerd -o http://188.226.166.44:19328 -u mxH9qc6QJu5r9UkgLhRhgsGX7AKb2hYz94+0.000022 -p -x
-
Ok wrapper, I’ll keep it on then! Only 10~15 kH is low… sorry, but that’s all I have.
Just drop me a line if you need me to stop mining.
-
Cheers for that, it doesn’t need to be excessive hash rate to tick over. Although we found doing the testing needed more hash rate. In fact there is a lower test hash rate limit built into the code, where the difficulty will go no lower…
If you follow the guide to compile in a Virtualbox, you can make a wallet on the testnet. I’ve been testing coin control. You can put a testnet3 address in, and see the coins you are “earning”, before it gets reset…
-
Tomorrow I will issue RC2 with a new testnet to start from scratch with the changes implemented in stages to give us some more data to work from. I will put this out on Facebook and Twitter so please subscribe to get notified of RC2.
-
So I’d better compile the wallet for Bushstar’s new testnet then…
-
Re: Kimoto Gravity Well, may be susceptible to Time Warp attack. Peter sent me this…
Nite69 put a fix out for the time warp exploit in KGW, not seen it implemented in a coin yet.
-
Since the smallest interval between blocks is 1 second, zero or negative values should not be allowed. This KGW patch eliminates the possibility of many blocks to have the same time stamp.
-
Most coins have timewarp blocks, when I looked at it. So, they are not due or only due to KGW.
Although, I also understood older blocks were not allowed, and those transactions would go to the next block? Needs a closer inspection how those timewarp blocks get past validation…We didn’t see any in the testnet, even with massive hash swings.
-
I see KGW has no difficulty limiting at all. It gets straight to setting a new difficulty value once the history search crosses EventHorizonDeviation[Slow,Fast]. That’s definitely not good.
-
I agree, one of the KGW issues we noted, that it over reacted somewhat to change.
This theoretically could be a good thing, the large hash change generates a higher difficulty. However, that is open for exploitation and a main reason for leaving in difficulty damping, just in case. Which is what I suggested on Franko coin forum.
-
Good watch
-
I see KGW has no difficulty limiting at all. It gets straight to setting a new difficulty value once the history search crosses EventHorizonDeviation[Slow,Fast]. That’s definitely not good.
It’s definitively a bad idea to implement Kimoto without a limitation of the max diff change, especially if you apply it at every block.
The risk would be much less with a retarget of every 16 block or more.
But we are not implementing Kimoto and we have a limit for the max diff change anyway.
-
Has anyone read the Litecoin Development Team’s official position on whether to change Litecoin’s proof of work at https://litecointalk.org/index.php?topic=18166.0 ?
-
Gentlemen, We must as soon as possible .
GC 6M Scrypt ASICs will be selt.
https://bitcointalk.org/index.php?topic=556885.new;boardseen#new -
Has anyone read the Litecoin Development Team’s official position on whether to change Litecoin’s proof of work at https://litecointalk.org/index.php?topic=18166.0 ?
That Lityecoin post is about a hard fork due to a POW (hashing/proof of work) not ReTargeting the difficulty calculation and changing the transaction speed.
POW is being discuses on another thread.
We are very aware hard forks are problematic, that is why we will give advance notice of a fork and have done extra specific extra fork testing.
There has already been much discussion on handling hard forks, I have advised the need to give good advance notice of any POW hard fork.
Interesting post though.
-
Hard forks are problematic, but this issue should be resolved.
I am mining on testnet:
minerd --freq=600 --gc3355=\\.\COM11 -o http://188.226.166.44:19328 -u TRN7fTZa8ezTnpzj43m2hV5w9pHdp8MX29 -p -x
-
Multipools make no sense for long confirmation time coins. Say a pool checks the difficulty every 5 minutes. Feathercoin has a 2.5 minute block time. Say the fast blocks when it gets hammered are 10 secs. The difficulty with any algo will have a temporary curve. With 10 sec blocks, it will bounce faster than a 5 minute polling multipool will even notice it. If the confirmation time were 5 minutes, the bounce would be even faster and the time of the attack would be shorter.
Having short confirmation times makes you react faster, but you react softer and you stay on the multipool radar longer.
-
The main problem with any blocks times below 1 min is that currently they can start to produce stales.There is always going to be compromise, between security and flexibility to react (when calculating difficulty).
Essentially the new FTC algorithm (eHRC) will make multipools run more fairly (in the energy they use to create coins compared to loyal miners). In order to create coins they need to mine, but just not for “free” by exploiting loopholes in ReTargeting times.
As there is no perfect technical solution to “evil pools”, they will end up breeding the coin police. nice one.
-
Catcoin’s PID is reacting well, although it’s still a bit aggressive.
We know how to detect incoming and outgoing hashrape though.
We’re going to add that to the algorithm.
