Feathercoin Core 0.11.1.1 Launch

Wellenreiter

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

lizhi

set COINBASE_MATURITY to 100

https://github.com/FeatherCoin/Feathercoin/commit/d8d8e80e98e2f1af09a7c15293368972fb2ed43c

Wellenreiter

@lizhi said:

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

There are two different procedures in main.cpp, with different return values:

Around line 1068:

int CMerkleTx::GetBlocksToMaturity() const
{
    if (!IsCoinBase())
        return 0;
    return max(0, (COINBASE_MATURITY+1) - GetDepthInMainChain());
}

Around line 1710:

int GetRequiredMaturityDepth(int nHeight)
{

    if (nHeight >= COINBASE_MATURITY_SWITCH)
{
        return COINBASE_MATURITY_NEW;
    }
    else
    {
        return COINBASE_MATURITY;
    }
}

and finally around line 1747:

if (coins.IsCoinBase()) {
                if (nSpendHeight - coins.nHeight < COINBASE_MATURITY)
                    return state.Invalid(
                        error("CheckInputs() : tried to spend coinbase at depth %d",   nSpendHeight - coins.nHeight),
                        REJECT_INVALID, "bad-txns-premature-spend-of-coinbase");
            }

The last one is in procedure checkinputs, so I think it is not critical.

I think the 2nd one would create errors, if not returning the same value for all clients, at least for mining clients, but again, as the code is the same in 0.8.7.3 and 0.9.3.1 I don’t see a problem here.

lizhi

GetRequiredMaturityDepth is unused . No switch to COINBASE_MATURITY_NEW.
COINBASE_MATURITY is used, but it is 30 .

Wellenreiter

@lizhi
Then let’s patch it to 100 ! :-)

We even may use COINBASE_MATURITY_NEW, if there is no other way to switch back to maturity 100