Feathercoin Fork

ghostlander

Run feathercoin-qt -disablesafemode
or put disablesafemode=1 to your feathercoin.conf

bsotnikow

@ghostlander hmm, thanks. I’m on mac though so I have no “Run” feature, is this something i do using terminal? I also did a full scan of my drive and have no files named feathercoin.conf. Also looked in applications support and the feathercoin-qt package contents myself as well, no luck.

RIPPEDDRAGON

I would guess as apple is a unix system that would would have to do it command line

bsotnikow

@RIPPEDDRAGON No luck. I can open feathercoin-qt, but the -disablesafemode command is not valid.

Here’s what I enter:
open -a feathercoin-qt -disablesafemode

And this is what i get back:
open: invalid option – d

Wellenreiter

@bsotnikow

try a double -

so ‘–disable safemode’

ghostlander

@bsotnikow Locate .feathercoin directory in your home directory and create a feathercoin.conf file there.

We have a problem with v0.9 rather than other releases. A pool operator reported more orphans than valid blocks for his pool 2 weeks ago.

https://bitcointalk.org/index.php?topic=178286.msg13944056#msg13944056

When he downgraded v0.9.3 to v0.8.7 per my advise, no more excessive orphans. I didn’t investigate it any further, though noted. It seems v0.9 has compatibility issues. I’m sure it isn’t NeoScrypt related. Maybe something transaction related. If v0.9 accepts certain transactions as valid while v0.8 and v0.11 don’t, we can have such a situation.

bsotnikow

Thanks! Creating a .conf file worked. I’m synced again.

bsotnikow

If its transaction related, I wonder if increased traffic from the recent price spike and trade volume contributed.

GMC

@ghostlander
Where do we stand? At give-me-coins we have been mining a bunch of blocks with 0.9.3.

ghostlander

@GMC You have also mined a bunch of orphans. 14 of the last 30 FTC blocks found by your pool prior to the fork were orphans. 47% miss rate is something to think about.

RIPPEDDRAGON

Bittrex is having issues related to this as an fyi

@Bushstar miss you!

GMC

@ghostlander True. But we tested 0.11.2 and had problems also. And staying with 0.8.7 represented a risk also.

ghostlander

@GMC What risk? The basic functionality including the ACP is the same.

GMC

@ghostlander If I recall correctly, 0.8.7 doesn’t allow v3 blocks. With 0.11.2 out, a v3 block could be mined at any moment stopping all v0.8.7 wallets. That sounds like a risk to me.

ghostlander

@GMC Speaking technically, v3 (DERSIG/BIP66) and v4 (CHECKLOCKTIMEVERIFY/BIP65) are forced by v0.11 only when 95% of the network produce these blocks. However v0.8 rejects anything other than v2 for a reason. Therefore v3 or v4 blocks are a hard forking change which isn’t going to happen any time soon. Although I can add support for BIP66 and BIP65 to v0.8 while keeping these blocks labelled v2.

ghostlander

I have just finished v0.8.7.3 with the BIP66 (Strict DER) support and checks to make sure such a fork won’t happen again.

https://github.com/ghostlander/Feathercoin/commits/master-0.8

FlatBlack

@ghostlander so, this node is ‘back-on-track’ again for FTC-android-wallet…?
*me at ‘+8:00’ time-zone if referring time-display as picture below attached
alt text

lizhi

up to now, 0.9.5 sync normal, but 0.11.2 are stuck. 0.9.5 is version 3.

lizhi

I create a mechanism that when the 75% hashrate agree, blockchain upgrade automatically.
0.8.7.X and 0.9.3 use version 2, 0.9.5 use version 3, 0.11.2 use version 4.

Wellenreiter

After analysing the behavior of the different clients and the timing of the events leading to a fork the most probable reason for the fork is the follwing:

Client version 0.8.X and 0.9.3 use a block format version 2
Client version 0.9.5 uses a block format version 3

What happened:

A pool using 0.9.5 as client generated a block and annouced it to be inserted into block chain
As this block was using block format 3, all 0.8.7.x/0.9.3 clients rejected that block, while all 0.9.5 clients accepted it and inserted it into their local copy of the block chain
Then a pool using 0.8.7.x found a block and annouced it to be inserted into the block chain.
all 0.8.7.x and 0.9.3 clients accepted that block, while 0.9.5 clients flagged it as orphan, as they already had a block with that block number/height.

The result was the split into two chains, where 0.9.5 clients where on a different trunk of the chain than all other clients.

For for all pool operators and miners who to solo mining on a client with version 0.9.5 please change your client to 0.8.7.3 or 0.9.3