Feathercoin Fork

bitboy11

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.5

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

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?

Wellenreiter

@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.

bitboy11

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?

AcidD

@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!

lizhi

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=100

two:
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.

ghostlander

@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

Wellenreiter

@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.

AmDD

@Wellenreiter said:

@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.

is solo mining possible? I didnt think it was

wrapper

is solo mining possible? I didnt think it was

Solo mining is always possible. The only time it can be un -viable is where the number of miners / hash rate >>> hash rate you have. Which is why people form pools, and sometimes you might not have enough hash to earn in a pool.

Currently, it should be possible to solo mine FTC with a reasonable home rig (~200 KHash) . You might have to wait a couple of weeks / month to get a block.

That based on experience recently with our p2pool. It got split off from other pools, with the fork and thus effectively “solo” mining with 200KHash.

It would be interesting to see if anyone tries solo mining…

AmDD

@wrapper said:

is solo mining possible? I didnt think it was

Solo mining is always possible. The only time it can be un -viable is where the number of miners / hash rate >>> hash rate you have. Which is why people form pools, and sometimes you might not have enough hash to earn in a pool.

Currently, it should be possible to solo mine FTC with a reasonable home rig (~200 KHash) . You might have to wait a couple of weeks / month to get a block.

That based on experience recently with our p2pool. It got split off from other pools, with the fork and thus effectively “solo” mining with 200KHash.

It would be interesting to see if anyone tries solo mining…

I understand the risk of solo mining in relation to profitibility. Im asking if its physically possible. My understanding was that Bitcoin and Litecoin both removed the code to allow solo mining, since Feathercoin is a fork of Litecoin and now based on Bitcoin Core I question if the mining code was added back to Feathercoin. Ive also tried to solo mine FTC awhile back and had no luck. There should be a thread on it somewhere here.

RIPPEDDRAGON

Isn’t solo-mining purely get work based not stratum hence why nsgminer wont work? Do you have to run some sort of stratum to get work proxy?

Wellenreiter

@RIPPEDDRAGON

It should be possible to simply start feathercoin-qt or feathercoin with -gen option to start solo cpu mining

With rpcuser and rpc password set, you also can point a miner to the client in order to do GPU mining.

ghostlander

Solo mining works through Getwork. It’s broken in SGminer still. NSGminer works fine.

wrapper

Fork?
Give me Coins on Wong Version AGAIN? - I have resurrected this thread so get help :

---- ACIDDUDE FOUND THIS 2016-06-30 11:38:08

CheckForkWarningConditions: Warning: Large valid fork found
forking the chain at height 1277149 (df7599227e348c49fadb6812af71aa8daf31ad251e3fa41ff87877f9fb7cc4ec)
lasting to height 1277183 (2956a078a7969ba12cbb0dc5abbf86bfec22fe37cadd68ad416ae892708fbb8e).
Chain state database corruption likely.

There is a technical issue thread to fix it and report back :

http://forum.feathercoin.com/topic/8600/fork-warning-large-valid-fork-found-forking-the-chain-at-height-1277149

thebaron

Is BIP65 CheckLockTimeVerify still embedded in FTC? I’m very interested in trading on Blocknet and just want to check that feathercoin doesn’t have anything stopping it from running on the DEX.

wrapper

@thebaron said in Feathercoin Fork:

CheckLockTimeVerify

I think that’s (CheckLockTimeVerify) in 0.11 and we haven’t / reviewed or released that yet.

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki