[Dev] Hard fork to change retarget, averages and block time
-
It may be a problem over time because GetNextWorkRequired() is called while verifying every block in the chain. This approach is also more vulnerable to time travel attacks. PPC retargets every block, but their retarget code is rather simple. They don’t look back 500 blocks or so on every retarget.
Hi Ghostlander,
Because of your concerns, we are doing some extra work looking into GetNextWorkRequired(). So far it would seem that confirmations are not based on looping back through the all blocks in the chain so your fears are unfounded.
We also don’t look back 500 blocks in any of the simulated difficulty adjustment solutions that were tested.
-
Testing - Update
The Testnet has moved to http://188.226.166.44:19328
For those of you that are used to have a redundant configuration, or in case the above pool is not available due to upgrades or new setups, you can add the second testnet pool:
If we need to modify the software on the pool, we will do it one server after the other, so if you have the second server configured changes will be transparent to you.
We need a small number of CPU miners ~ 50 KHash and you can use the test p2pool so there is no extra configuration.
minerd -o http://188.226.166.44:19328 -u Address+0.000011 -p -x
You can replace Address with a real Test address. I have updated the guide to compiling a test wallet in a VirualBox, to include the new test version git link.
If you do compile in a test box, it is then a good place to get used to Coin Control, by sending some test coins about. Warning: At this stage it must be kept isolated and DON’T update your normal wallet to the test version.
Here is the github link, for test wallet: WARNING, it is under development, so recompiles will be required, do not use as your normal wallet!
For those not wanting to complile the wallet themself I can provide precomiled binaries and also installation packages for a couple of Linux distributions and a short instruction how to install the testnet wallet.
If you don’t want to install any new software on your system, you still can help with the tests, by just providing hashing power.
You can use a wallet address from your normal wallet to login to the pool server, but of course you will not receive any coins from the testnet.
-
Interesting discussion re: What is a Hard or Soft Fork?
A soft fork introduces a new protocol functionality without a threat to split the network. For example, PXC will do a soft fork tomorrow with a block limiter. This feature requires a hard fork usually, but we can force the old clients to accept results of the block limiter through the ACP. Those new blocks which violate the block limiter will never be checkpointed. The updated nodes will reject them simply and the outdated nodes will re-organise according to the ACP.
-
I am minging on testnet node. It is about 250Khash/s, I hope for your help.
minerd -o http://188.226.166.44:19328 -u lizhi_miner+0.000011 -p -x
-
Thanks for everyone who has helped, is helping, provide some hash for the testnet.
The main tests for the new algorithm (Enhance Hash Rate Compensation, eHRC) are pretty amazing and it works as simulated.
eHRC simply extends the current hash change compensation calculation by taking the long and short term hash rate into account when calculating the difficulty for the next block. It is easy to understand, small amount of code and introduces no novel features that could have unknown variabilities.
We are keeping the testnet open for some longer term soak in testing. It will then be up for testing the new hashing ASIC resistant hashing algorithm.
You don’t have to download or compile test wallets, just attach a CPU miner on the testnet will help keep it going, we can switch to normal mining so you will get paid if a standard address is added. Otherwise, your name, on the testnet p2pool charts, seems cool.
I’ll post here when the soak test is complete.
e.g. cpuminer
minerd -o http://188.226.166.44:19328 -u YouRNameOrFTCorFTCTestaddress+0.000022 -p -x -
I just put some cores of my server at work on the testnet!
Hope I got the name right…
-
Jep, you did :D
Your miner shows up in the statistics.
You can check on http:188.226.166.44:19328
Thank’s a lot for supporting the testnet with some hashpower
-
The charts are on
-
maximum change on difficulty must be fixed ?
Thanks again Lizhi - for help testing Rep++
Just checking that we didn’t miss any points now there is a tested version of Feathercoin 0.8.6.1 available for PublicBeta testing.
**What were some of the reasoning or justification for the design decisions, such as retaining damping and difficulty change limitation? **
1. We can not defeat coin hopping, the pools are obviously a part of the crypto currency environment and infrastructure.
Coin hopping is the symptom not the problem.
The cause of the problem was found to be large Hash switches. In this case it was obvious that we needed to ReTarget the difficulty each block, to compensate for hash switches. That was the simplest software update that acted to make difficulty adjustment fairer.
2. After modelling this change it was obvious that a coin hopper could still gain network advantage because the old averaging window was too long into the past.
However, just shortening the window re-opened us up to some historic network exploitation vectors. Adding the 2 extra timespans solved that problem, as it takes short term change into account, but is stable over the long and medium term. Which of course, was what eHDC was designed to do.
By modelling all the proposed solutions we were able to monitor all their responses to various hash rate scenarios.
Sometimes small changes in parameters had little beneficial effect so they were left as is. Also, as we were also changing to one minute block time, that was expected to have an effect. In the end, it didn’t for some parameters, which were there to solve other problems, and “if it ain’t broke, don’t fix it”.
All the other solutions worked as well (Euler, Kimoto), and it was simplicity of eHDC was its main benefit.
That was the easy bit, then Bushstar had to program it!
Don’t forget the testnet is still up. You can compile a Seperate test wallet inside Virtualbox with this guide.
You can view p2pool on this
http://188.226.166.44:19328/static/
You can test mine on this CPU preferred.
e.g. CPU miner
./minerd -o http://188.226.166.44:19328 -u mmVjNeDvYKUsCZop8yGeZScdkeZm2pc1T2+0.000022 -p -xor minerd -o http://188.226.166.44:19328 -u YouTestAddresOrVanityAddress+0.000022 -p -x
or minerd -o http://188.226.166.44:19328 -u FTCAddresss+0.000022 -p -x
Next tests will be potential hashing algorithm changes, hard forks…
-
Just checking that we didn’t miss any points now there is a tested version of Feathercoin 0.8.6.1 available for PublicBeta testing.
Hey wrapper,
do you still need the hashing power on the testnet?
-
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.
