[Dev] Hard fork to change retarget, averages and block time
-
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.
-
OMGZ. Multipools are reading the difficulty of the SOLVED BLOCK. Not the difficulty of the CURRENT BLOCK. ROFL. I’m confident many of the coin stat sources make the same mistake.
BAHAHAHA.
-
Hey, don’t tell them everything we know!
-
Looks like Feathercoin 0.8.6.1 is about to be released.
Thanks to Wellenreiter and Bushstar to all the works to make this happen. We’ve completed 2 weeks of live testing at the weekend, and there has been no further issue identified.
eHRC has performed completely as specified, even with the greater hash variability of the testnet. It bodes very well that it will perform as well as other methods of Hash Rate compensation, but with only minor changes to the standard protocol settings and calculations.
The release also includes transaction time reduction to one minute, which would be would be basically incredible, just by it’self.
We now need big publicity, so everyone knows this is a mandatory hard fork.
-
We need to define and announce a block number and an estimated date for the fork, so everyone can prepare in advance and install the new clients.
We also should pro-actively contact the pool operators, if we know their forum names or other contact data.
When 0.8.6.0 was released, some pool operators missed the news…
-
Wow great news thanks for all the hard work guys.
-
I don’t thing 0.8.6.0 made much difference to the pools whereas the change to 0.8.6.1 will be mandatory. The messaging system is important for wallets upgrades, but pools and miners will need to be informed more creatively.
There are massive changes for a point release…
For once, I would be for a “swarm” of members helping out, contacting their pool, or miner friends etc.
I think Peter is finalising the release and fork block now. I understand he is looking at one week.
But perhaps two weeks would be better, we would still need huge publicity campaign.
The changes will particularly welcome by small and loyal miners, so it should be heavily supported It’s a real chance for community action to get these changes out quick.
-
Incredible guys. Great work.
Let’s make history shall we?
-
Could this receive a highlight on our home page along with a link for miners and pool operators to go to for what their action items are?
-
Could this receive a highlight on our home page along with a link for miners and pool operators to go to for what their action items are?
good idea Matl. we will need a big push. Everything and the kitchen sink. You can all help.
Bush is working on a release plan, should be out soon.
-
The testing is complete and the results are everything that the simulation said it would be. We are all very pleased with the results and will now put out the new version with two weeks notice on the hard fork. I am in Germany at the moment but have my Mac with me which has dual boot.Right now I am setting up a build environment on Windows with the latest OpenSSL and tomorrow will create the new clients. Once the new version is out I will make an announcement thread in general and send out messages on Twitter, Facebook and Reddit so keep an eye out.
-
This may be out of context but are we affected by the heartbeat openssl vulnerability? Could this be looked at before the release or maybe be a separate project?
Your mention of openssl rang a bell.
Great news about the test results guys I’ll start rounding up a mailing list.
Do we need to need to contact merchants such as pock.io and others aswel?Its a long shot but could we contact coindesk and ask for a writeup on our multi pool defence and new block time?
-
Good explanation :)
+1
By the way, all precompiled packages for the linux distributions should use dynamic links to openssl, so it is important, that users update their openssl packages, if this is not done automatically
