Feathercoin Fork
-
Can anyone say what is current status?
What client is safe to use ?
How to check whether wallet is on main chain ? -
@coinotron said:
Can anyone say what is current status?
What client is safe to use ?
How to check whether wallet is on main chain ?Safe clients are 0.8.7.3, 0.9.3.1 and 0.9.5
no
According to Ghostlanders observations 0.8.7.3 is more effective for pools than the 0.9.3.1 and 0.9.5Outdated versions are < 0.8.7.0 (no neoscrypt)
0.8.7.0, 0.8.7.1, 0.8.7.2 (no BIP66 support) which are not compatible with the versions 0.9.5 and 0.11.x -
Thanks.
What about network, is it still split into different chains?
Is it safe to transfer coins ? -
@bsotnikow said:
If its transaction related, I wonder if increased traffic from the recent price spike and trade volume contributed.
Unless you like Russian Roulette, i highly recommend not sending coins.
-
The hasrate reported is back to the level we had before the fork.
I think, that the block chain is consolidated now.
Still: PLEASE UPDATE YOUR CLIENTS!!!
-
hello,
I have been trying to update my wallet but i always get this message “the program can,t start because libwinpthread-1.dll is missing from your computer…” could someone explain me , I am currently using Qt version 4.8.5thank you
fred -
I assume, that you are on Windows and try to install the binary version 0.9.3.1 provided by Lizhi.
I’m not a windows specialist, so I only can give tips here:
- try to find out, which windows software package provides libwinpthread-1.dll
- google ‘libwinpthread-1.dll missing on windows’ or similar. I assume it will be contained in qt5, but I’m not sure.
- install the software you find and install the client.
- if you can’t find the software providing the dll
- try to compile and install client version 0.8.7.3 which uses qt4, that you have on your pc.
@all: is there anybody, who can provide a windows binary version 0.8.7.3?
- try to find out, which windows software package provides libwinpthread-1.dll
-
thanks for your answer, will try to install version 0.8.7.3, when i get the link,
-
Windows executable
https://github.com/ghostlander/Feathercoin/releases/tag/v0.8.7.3-ftc
-
I have downgraded from 0.9.5 to 0.8.7.3
Thanks guys!
-
Same here from 0.9.5 to 0.8.7.3, and no need to download block list - it have eaten 095. One thing - in 0.8.7.3 about shows 0.8.7.0, a bit confusing, but just a remark. Thanks!
-
@MrBeen It shows “Feathercoin version v0.8.7.3”
-
Thanks Ghost I used your source to compile 0.8.7.3 on my raspberry pi, so I’ve got a node up again, although its currently catching up and probably will be for another day.
-
@Wellenreiter said:
Safe clients are 0.8.7.3, 0.9.3.1 and 0.9.5
no
According to Ghostlanders observations 0.8.7.3 is more effective for pools than the 0.9.3.1 and 0.9.5For 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
I’m not a pool miner nor am I solo mining. I am running version 0.9.5 Do I have to downgrade as well?
-
@bitboy11 If you are not mining 0.9.5 should be save for you.
Just to be clear:
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
It is 0.9.3.1 is the actual production release in the 0.9.x versions of the wallet.
0.9.5 should be ok for non- miners only. -
It is almost 3 weeks since I asked the question and received an answer but today I just launched my 0.9.5 wallet only to see a message stating: “Downgrade to 0.9.3.1”
So I’m asking again if it is still OK to stay at 0.9.5 so long as I’m not Pool Mining or Solo Mining?
-
@bitboy11 said:
It is almost 3 weeks since I asked the question and received an answer but today I just launched my 0.9.5 wallet only to see a message stating: “Downgrade to 0.9.3.1”
So I’m asking again if it is still OK to stay at 0.9.5 so long as I’m not Pool Mining or Solo Mining?
I believe you’re correct. if you mine with 0.9.5 you have a chance of generating the newer(?) block version.
You should be able to use the 0.9.5 client/wallet to send and receive FTC as long as you DONT mine against that client.
I hope @Wellenreiter or someone will slap me down with a knowledge bomb if i’m wrong…eeek!
-
A man mined a block with 0.9, cause a fork. Now our network has 2 different with 0.8.
one :
0.8 BASE_MATURITY=100
0.9 COINBASE_MATURITY=30
0.11 COINBASE_MATURITY=100two:
powLimit=uint256S(“00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff”)
not uint256S(“0000003fffffffffffffffffffffffffffffffffffffffffffffffffffffffff”)What is COINBASE_MATURITY ?
Coinbase transaction outputs can only be spent after this number of new blocks (network rule).What is powLimit ?
It is starting difficulty.When Core check ProofOfWork, If Target > PowLimit , then check ProofOfWork error.
-
@lizhi Coin base maturity must be set to 100 confirmations for compatibility reasons. No need to change it either. Why v0.9 makes use of incorrect value is another question. Yes, it can fork the network.
The PoW limit is the highest target possible which results in the lowest difficulty possible.
uint256S(“00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff”) = ~uint256(0) >> 20
There was a difficulty reset while switching to NeoScrypt.
uint256S(“0000003fffffffffffffffffffffffffffffffffffffffffffffffffffffffff”) = ~uint256(0) >> 26
-
@ghostlander said:
@lizhi Coin base maturity must be set to 100 confirmations for compatibility reasons. No need to change it either. Why v0.9 makes use of incorrect value is another question. Yes, it can fork the network.
The PoW limit is the highest target possible which results in the lowest difficulty possible.
uint256S(“00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff”) = ~uint256(0) >> 20
There was a difficulty reset while switching to NeoScrypt.
uint256S(“0000003fffffffffffffffffffffffffffffffffffffffffffffffffffffffff”) = ~uint256(0) >> 26
I think, the reason for v0.9 using 30 confirmations only is caused by the fact, that the code-base was switched from the Litecoin code to the Bitcoin code as upstream code base and this parameter was not adapted.
For me the correct solution is to change to 100 confirmations for all versions.
This means to create a patch for v0.9.x and publish it.We also need to test the compatibility of 0.8.7.3, 0.9 and 0.11 in the testnet before implementing anything on the main net.
Possible testnet setup:
- one group of mining nodes on 0.8.7.3
- one group of mining nodes on 0.9.3.1
- one group of mining nodes on 0.11.x (latest version)
Then gradually reduce the hashrate from the 0.8.7.3 nodes toward 0.9.3.1 and then to 0.11.x and check, how the testnet behaves.
I skip 0.9.5 here as I don’t see this version as a production version.
I think we would need at least 30 (= 3 groups of 10 ) mining nodes with client running, which is easier to get with solo mining rather than pool mining.