Feathercoin Core 0.11.1.1 Launch

Wellenreiter

@wrapper said:

should that be mFTC? in settings

plus : updated source code Link at Thread header to version 0.11.2 on Github

Will check that next time I start the gui. Currently testing the daemon

sync is ongoing
importing a private key for a wallet address is working

Wellenreiter

A comment from my side about 0.11.x:

for me both versions are currently in Beta test, as we

don’t have pre-compiled binaries (started to work on that yesterday)
have many references to “Bitcoin” in the help texts and some in the gui
don’t have a clear picture (or sould I say ‘1 don’t’? ) how the bc and network behaves, if the new block version is enforced
have no information of the status of pools, if when and how they’ll implement 0.11.2

But that is just my opinion. :D

What do others think?

mirrax

@Wellenreiter said:

A comment from my side about 0.11.x:

for me both versions are currently in Beta test, as we

don’t have pre-compiled binaries (started to work on that yesterday)

have many references to “Bitcoin” in the help texts and some in the gui

don’t have a clear picture (or sould I say ‘1 don’t’? ) how the bc and network behaves, if the new block version is enforced

have no information of the status of pools, if when and how they’ll implement 0.11.2

But that is just my opinion. :D

What do others think?

Looks like a valid points. I think it is important to push Core 0.11.2 so more people can test and feedback.
Also I would like to see 0.9.x features migrated to 0.11.2 (Lizhi is working on migration)

wrapper

Actually it is cool that we can test the new version on the live network, then go back to the previous version. Having more mechanisms to handle database upgrades and forks is pretty neat, and necessary in the long run…

Wellenreiter

@mirrax said:

…
Also I would like to see 0.9.x features migrated to 0.11.2 (Lizhi is working on migration)

another point to not advertize 0.11.2 and clearly flag it as “development only” version.

We can’t start to publish revisions and then implement changes, so we currently can’t make 0.11.2 a release yet.

From Github:

Tagging suggestions

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

If the tag isn’t meant for production use, add a pre-release version after the version name.  Some good pre-release versions might be v0.2-alpha or v5.9-beta.3.
Semantic versioning

If you’re new to releasing software, we highly recommend reading about [semantic versioning.](http://semver.org/)

I think those are simple and effective rules and we should try to adhere to them

Wellenreiter

@wrapper said:

should that be mFTC? in settings

plus : updated source code Link at Thread header to version 0.11.2 on Github

Actually the meaining is ‘Mega FTC’ :)
The gui offers:

FTC
kFTC
MFTC
mftc
µFTC

AcidD

Do any of the versions/wallets of FTC notify the user when there’s a new official release ?

Is there a way that can be broadcast on the network ? …like “hey guys…time to upgrade!”

wrapper

Funny you should mention that one reason “pchMessageStart.” - is required to be unique.

FTC had messages at one stage from LTC to upgrade, and Bush had to turn off that upgarde message facility to stop that happening. Not sure what keys you need to certify the message

mirrax

@aciddude said:

Do any of the versions/wallets of FTC notify the user when there’s a new official release ?

Is there a way that can be broadcast on the network ? …like “hey guys…time to upgrade!”

Should be, i think it was actually used before neoscrypt hardfork.

mirrax

@wrapper said:

Funny you should mention that one reason “pchMessageStart.” - is required to be unique.

FTC had messages at one stage from LTC to upgrade, and Bush had to turn off that upgarde message facility to stop that happening. Not sure what keys you need to certify the message

Yes, it was turned off because it was broadcasting LTC messages, but it was fixed and used before neoscrypt hard fork…

AcidD

Stoner Idea 1: Reward users for updating to latest version…somehow…

–
I don’t know how, I don’t know why…

lizhi

Please urgend update clients to 0.11.2.1 , it compatible 0.9.3.1 and fix testnet.

Download 0.11.2.1 http://www.ftc-c.com/pack4/feathercoin-setup.exe

alt text

Commits:
https://github.com/FeatherCoin/Feathercoin/commit/db2371aa8b2b4059250c55a182554741aeb7e114
https://github.com/FeatherCoin/Feathercoin/commit/ada92194bcf6be1e5d48a57ac2c2eb4b7ad78d03
https://github.com/FeatherCoin/Feathercoin/commit/4604c4d856e83d7e80d9fd18eca9f6d8a4417a08
https://github.com/FeatherCoin/Feathercoin/commit/4d32222f7fba8d6990dcac4e9f20152232a1d0c0

ghostlander

Coin base maturity has been 100 confirmations since the very beginning of FTC when block target has been set to 2.5 minutes. It’s 1 minute now yet we maintain 100 confirmations for compatibility and simplicity. Why do you change it to 30 confirmations for v0.11 out of a sudden?

lizhi

@ghostlander because our blockchain is 30 , pools are running 0.9.3.1 , it is 30. If I set 100 in 0.11.2 , cann’t work , get a error. After I set COINBASE_MATURITY = 30 , It is all right.

ERROR: CheckProofOfWork(): nBits below minimum work
CheckHeaderProofOfWork(), nHeight=1114378
ERROR: ProcessNewBlock: ActivateBestChain failed

lizhi

The same happens in PowLimit . Now mainnet’ PowLimit is uint256S(“00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff”) =(~uint256(0) >> 20) =504365055 .
not is uint256S(“0000003fffffffffffffffffffffffffffffffffffffffffffffffffffffffff”)=(~uint256(0) >> 26)=490733567

But it have not caused too much.

Wellenreiter

@Lizhi, did you also test the switch over to BIP66 with the warnings sent out, when ~60% (or whatever number) of clients are on the new version and the final switch, when 99% of clients are on the new version?

As we don’t have a any to any mesh in the network, there is a risk, that the 0.11.2.x client see a part of the network, where most clients are on a compatible version, while this is not the case for the full network.
Then the switch would occur and we may get a fork, if not all clients are compatible with the new version.

This is valid for mining clients only, of course, but needs to be tested in the testnet, before implemented on the mainnet.

ghostlander

@lizhi Most pools use v0.8. We can patch v0.9 to 100 confirmations.

Wellenreiter

@ghostlander said:

@lizhi Most pools use v0.8. We can patch v0.9 to 100 confirmations.

I support that!!

Wellenreiter

I’ve checked the code for 0.8.7.3 and 0.9.3.1 and I think the problem which was observed by Lizhi only exists in the test net.

On main net we are in COINBASE_MATURITY = 240 already:

From main.h:

/** Coinbase transaction outputs can only be spent after this number of new blocks (network rule) */
static const int COINBASE_MATURITY = 30;
/** Coinbase maturity after block 145000 **/
static const int COINBASE_MATURITY_NEW = 60*4;
/** Block at which COINBASE_MATURITY_NEW comes into effect **/
static const int COINBASE_MATURITY_SWITCH = 145000;

As we passed block 145000 long ago, we are on COINBASE_MATURTY= 60 *4

lizhi

No , I don’t think so. COINBASE_MATURITY_NEW is unuesd in main.cpp . We check Inputs with COINBASE_MATURITY.