Bitcoin Forum

Feathercoin - The Miner Update - Hard Fork Block 87948

The latest Feathercoin version 0.6.4.4 is now available and is a mandatory update. This update includes a hard fork of the block chain to accommodate the changes made in this patch. This hard fork should happen roughly around the 1st October which is only a week away.  To be able to send and receive Feathercoin after block 87948 you have to use the new client. Continuing to use old clients after the hard fork could result in the loss of coins.

Primarily this update is to further the refine of the difficulty adjust. Though the current Feathercoin difficulty which we changed to get us out of a tough spot it is not fair for long term miners who have to experience 41.4% swings on every adjust. The new code will adjust four times more frequently at 126 blocks but to approximately 9% which still gives the exact same overall adjust. To prevent the difficulty from being sent up or down too rapidly the current 504 sample window is being maintained and damping is being introduced to reduce fluctuations between extremes.

There have been long running discussion and arguments on the Feathercoin forum including simulations of various different options surrounding this solution. Feel free to take a look at the latest discussion here (https://forum.feathercoin.com/index.php?topic=3447.0).

To get the latest update please go to the Official Feathercoin Website and download the client from the homepage.

Official Feathercoin Website (https://www.feathercoin.com)

Changelog:
Move to 126 difficulty adjust with 504 averaging window and .25 damping
Reduce effectivness of Time Warp attack
Reinstate CAlert system
Make getnetworkhashps more accurate
Release Windows binary with QR encode

Great to see the work doesnt stop! ;)

How so?

If there is an even playing field (i.e. all participants agree to the rules of the network) how is that not fair?

Perhaps loyal miners would have been a better term.

In short, when the diff swings up 41% the hashrate drops to ~3Gh/s. The LOYAL miners, rather than hop to the next most profitable coin stick around and mine at a higher diff for 2+ days to bring the diff back down. Then when the diff does swing down by 41%, all the multipools and profiteers swing their miners back to FTC, the hashrate jumps to ~10Gh/s and so the good times (low diff) only lasts for 8 hours before swinging up again.

This update will stop the 41% bounce and limit it to 9%. There will be swings still of course but hopefully the effect will be reduced. Simples.

Of course, if you are not a loyal miner, you may not see the benefits, possibly the opposite but we're all about looking after the loyal guys in the community. ;D

That is all.

Why not then just remove all that and go with the most granular diff adjustment (i.e. after each block)?

I like the windows installer, a bit more pro than a lot of the other coins that you basically unzip.

Just perfect, no more diff traps for FTC!

Stickied for a day or so. I'll be watching the thread, but please send me a pm after the fork target block has been passed.

By profiteers you mean those guys who saved the coin from 51% attack back by switching to FTC when the diff dropped a couple months ago?

This webpage is not available  (https://www.feathercoin.com/)

Read the source code and you might learn something.

We experienced attacks where Feathercoin blocks were being created two hours into the future. This is the most that the protocol will tolerate and is the default of Bitcoin which has 12 blocks in that time period. We have 12 blocks in a 30 minute period and our code as been adjusted to reject blocks outside of that time period. So the attackers can still swing out time but not by as much.

With adjusts every 126 blocks (5.25 hours) having attackers swing our time by two hours would be a huge problem so we had to limit this in some way.

Just let this piece of shit coin die already.

Just read the whole things from start to finish on the FTC forum .

as you know i'm not a holder of FTC but i think these implementations help the FTC community -

particularly the 504 averaging window and .25 damping

in conjunction with the shortening of the time regarding the "Time warp" flaw. 

as this can help sure up security which ultimately supports confidence to the degree that you can control that aspect.

so good work.  

Survival is the best form of revenge... hmm that gives me an idea.

After updating, two blocks Multipool found were rejected with the following error:

ThreadRPCServer method=submitblock
ERROR: AcceptBlock() : rejected by synchronized checkpoint
ERROR: ProcessBlock() : AcceptBlock FAILED

What is the fix for this?

You can't fix this. This message means that another block is already accepted by network and successfully checkpointed. It seems that blockchain is too fast for the current checkpoints implementation/settings. You can switch it into advisory mode to prevent such events in the future.

But it's better to change checkpoints interval setting to 6-12 blocks.

Are you sure? The advanced checkpointing has been running since August, you should have noticed any problems like that ages ago. I am inclined to think it was something else.

So I basically got 2 orphans in a row is what you're saying?

You said those blocks got orphaned after updating but were those blocks minted before you updated or after?

Blocks found on the old chain will get orphaned by the new fork. If anyone wants to continue using 0.6.4.3 they would need to set ACP to advisory.

After updating.  They were the first two blocks found after we updated.

Yep. I think that immediate check pointing policy is evil.

Not everybody does review of the debug.log file for reject reason. In fact, only a few people does this.

Maybe. But immediate check pointing would cause such events too. That's why such policy shouldn't be used for the regular operation.

Agreed. That is why the block depth is set to 3 when ACP went live rather than 0 based on feedback from technical users in the crowd. This allows some natural reorgs.


Can you get me the times and block numbers?

I would like to find out why this did not work.

Unstickied due to fork date being reached, good luck guys  :)

Feathercoin version v0.6.4.4 (2013-09-19 10:40:03 -0700)
Startup time: 09/30/13 06:42:48
[...]
ThreadRPCServer method=submitblock
ERROR: AcceptBlock() : rejected by synchronized checkpoint
ERROR: ProcessBlock() : AcceptBlock FAILED
[...]
trying connection 195.59.191.91:9336 lastseen=2.1hrs
SetBestChain: new best=96756968b3c40a36bd2d  height=88291  work=36701685832636670  date=09/30/13 17:22:21
[...]
ThreadRPCServer method=submitblock
ERROR: AcceptBlock() : rejected by synchronized checkpoint
ERROR: ProcessBlock() : AcceptBlock FAILED
Flushed 11448 addresses to peers.dat  95ms
connection timeout
trying connection 98.180.48.36:9336 lastseen=13.3hrs
received block f9f880425fe123ef8908
SetBestChain: new best=f9f880425fe123ef8908  height=88387  work=36774223244962492  date=09/30/13 21:33:26
SetBestChain: 21 of last 100 blocks above version 1
ProcessBlock: ACCEPTED

3 is too little. PPC and NVC the both uses 6 as depth for PoS blocks, for example. Just compare the targets spacing and block depth... 10min vs. 2.5min && 6 vs. 3.

How many forks can this coin survive ?

We are now in a good position to increase the depth. The threat of 51% attacks seems to be reduced now, our difficulty swings are much less we are not seeing the drop off in hash power we saw before. I will bring this up on the Feathercoin forum to get feedback. Balthazar you are very welcome on our forums, we need you as an informed critic :)

https://forum.feathercoin.com


So far each fork has made Feathercoin better, stronger and more resillient. The first fork was because we faced the fact that Litecoin's difficulty adjust takes its hashpower for granted, this fork aims to keep the hashpower up by reducing the swings in difficulty and it reduces the effects of Time Warp attacks.