Feathercoin - The Miner Update - Hard Fork Block 87948

[flound1129]

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.

[1714924370]

1714924370

[1714924370]

1714924370

[1714924370]

1714924370

[1714924370]

1714924370

[1714924370]

1714924370

[Balthazar]

Are you sure?

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

The advanced checkpointing has been running since August, you should have noticed any problems like that ages ago.

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

I am inclined to think it was something else.

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

[bushstar]

Are you sure?

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

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.

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

Can you get me the times and block numbers?

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

[SaltySpitoon]

Unstickied due to fork date being reached, good luck guys  

[flound1129]

Are you sure?

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

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.

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

Can you get me the times and block numbers?

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

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

[Balthazar]

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.

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.

[xray]

How many forks can this coin survive ?

[bushstar]

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.

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.

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

How many forks can this coin survive ?

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.