Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS

[Lauda]

So the fix is coming soon. 

[mullick]

Yes major breakthrough last night with the help of balthazar

[Pmalek]

So it is hard fork?
And I must ask... Are you SURE that this fixes the issues? Better not release it yet if you are not sure...

[Balthazar]

Yes, it will fix all the issues caused by the bug. Just like with PHS case, the bug is quite simple and introduced by original developer after forking this project from NovaCoin.

P.S. It's also possible to include a hard-fork to change target limits and spacing, I haven't decided yet.

[GTX-DoX]

When will this be opened again for trade ? Why is it blocked anyways ?

[mullick]

So it is hard fork?
And I must ask... Are you SURE that this fixes the issues? Better not release it yet if you are not sure...

Yes I am fairly confident. The trouble was finding out why no other caps clones have been effected. This simple yet rather tricky little bug was hard to locate for me but to the more experienced eye was easier to pinpoint. I will be taking the updates balthazar puts out and adding the other fixes caps needs as well as.

As the stake system functions its not doing what is is designed to do. Users are really not protecting the network with such short block times and low block maturity. It is not decided if I will address these separate issues at a later date or roll them all into one update while we are doing the hard fork now

The problems have arisen from the High starting difficulty caps was born with :

Caps: Note the minimum difficulty for Proof of Work is much higher than that of Proof of Stake

Code:

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 30);
static CBigNum bnProofOfStakeLimit(~uint256(0) >> 24);

NVC: Note PoS difficulty is set higher than PoW difficulty

Code:

CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // "standard" scrypt target limit for proof of work, results with 0,000244140625 proof-of-work difficulty
CBigNum bnProofOfStakeLegacyLimit(~uint256(0) >> 24); // proof of stake target limit from block #15000 and until 20 June 2013, results with 0,00390625 proof of stake difficulty
CBigNum bnProofOfStakeLimit(~uint256(0) >> 27); // proof of stake target limit since 20 June 2013, equal to 0.03125  proof of stake difficulty

The function the PoS blocks were failing and leading to the issues when combined with other factors was computeminwork() as seen below in Caps. It was originally believed since it was never adjusted to match the shorter nTargetTimespan it was causing the issues. But there was no indication as to why no other clones had been effected (as the code for this was identical in all). But I knew it was failing that function and obviously had never been correctly adjusted. So in 1.4.1 this function was lowered from 24 * 60 * 60 to the value below but the issue remained:

Code:

static const int64 nTargetTimespan = 0.16 * 24 * 60 * 60;  // 4-hour
static const int64 nTargetSpacingWorkMax = 12 * nStakeTargetSpacing; // 2-hour

//
// minimum amount of work that could possibly be required nTime after
// minimum work required was nBase
//
unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
{
    CBigNum bnTargetLimit = bnProofOfWorkLimit;

    CBigNum bnResult;
    bnResult.SetCompact(nBase);
    bnResult *= 2;
    while (nTime > 0 && bnResult < bnTargetLimit)
    {
        // Maximum 200% adjustment per day...
        bnResult *= 2;
        nTime -= 0.16 * 24 * 60 * 60;
    }
    if (bnResult > bnTargetLimit)
        bnResult = bnTargetLimit;
    return bnResult.GetCompact();
}

As you can see it is calculated using the bnProofOfWorkLimit which is much higher than the bnProofOfStakeLimit. This has never been an issue with any other PoS implementation because bnProofOfStake is usually higher

NVC uses a different function as Balthazar has a independent development path from PPC. This function is correct for NVC as it has 10 minute block spacing and a 1 week nTargetTimespan:

Code:

//
// minimum amount of work that could possibly be required nTime after
// minimum proof-of-work required was nBase
//
unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
{
    return ComputeMaxBits(bnProofOfWorkLimit, nBase, nTime);
}

Code:

//
// maximum nBits value could possible be required nTime after
//
unsigned int ComputeMaxBits(CBigNum bnTargetLimit, unsigned int nBase, int64 nTime)
{
    CBigNum bnResult;
    bnResult.SetCompact(nBase);
    bnResult *= 2;
    while (nTime > 0 && bnResult < bnTargetLimit)
    {
        // Maximum 200% adjustment per day...
        bnResult *= 2;
        nTime -= 24 * 60 * 60;
    }
    if (bnResult > bnTargetLimit)
        bnResult = bnTargetLimit;
    return bnResult.GetCompact();
}

[digitalindustry]

So it is hard fork?
And I must ask... Are you SURE that this fixes the issues? Better not release it yet if you are not sure...

Yes I am fairly confident. The trouble was finding out why no other caps clones have been effected. This simple yet rather tricky little bug was hard to locate for me but to the more experienced eye was easier to pinpoint. I will be taking the updates balthazar puts out and adding the other fixes caps needs as well as.

As the stake system functions its not doing what is is designed to do. Users are really not protecting the network with such short block times and low block maturity. It is not decided if I will address these separate issues at a later date or roll them all into one update while we are doing the hard fork now

The problems have arisen from the High starting difficulty caps was born with :

Caps: Note the minimum difficulty for Proof of Work is much higher than that of Proof of Stake

Code:

static CBigNum bnProofOfWorkLimit(~uint256(0) >> 30);
static CBigNum bnProofOfStakeLimit(~uint256(0) >> 24);

NVC: Note PoS difficulty is set higher than PoW difficulty

Code:

CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // "standard" scrypt target limit for proof of work, results with 0,000244140625 proof-of-work difficulty
CBigNum bnProofOfStakeLegacyLimit(~uint256(0) >> 24); // proof of stake target limit from block #15000 and until 20 June 2013, results with 0,00390625 proof of stake difficulty
CBigNum bnProofOfStakeLimit(~uint256(0) >> 27); // proof of stake target limit since 20 June 2013, equal to 0.03125  proof of stake difficulty

The function the PoS blocks were failing and leading to the issues when combined with other factors was computeminwork() as seen below in Caps. It was originally believed since it was never adjusted to match the shorter nTargetTimespan it was causing the issues. But there was no indication as to why no other clones had been effected (as the code for this was identical in all). But I knew it was failing that function and obviously had never been correctly adjusted. So in 1.4.1 this function was lowered from 24 * 60 * 60 to the value below but the issue remained:

Code:

static const int64 nTargetTimespan = 0.16 * 24 * 60 * 60;  // 4-hour
static const int64 nTargetSpacingWorkMax = 12 * nStakeTargetSpacing; // 2-hour

//
// minimum amount of work that could possibly be required nTime after
// minimum work required was nBase
//
unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
{
    CBigNum bnTargetLimit = bnProofOfWorkLimit;

    CBigNum bnResult;
    bnResult.SetCompact(nBase);
    bnResult *= 2;
    while (nTime > 0 && bnResult < bnTargetLimit)
    {
        // Maximum 200% adjustment per day...
        bnResult *= 2;
        nTime -= 0.16 * 24 * 60 * 60;
    }
    if (bnResult > bnTargetLimit)
        bnResult = bnTargetLimit;
    return bnResult.GetCompact();
}

As you can see it is calculated using the bnProofOfWorkLimit which is much higher than the bnProofOfStakeLimit. This has never been an issue with any other PoS implementation because bnProofOfStake is usually higher

NVC uses a different function as Balthazar has a independent development path from PPC. This function is correct for NVC as it has 10 minute block spacing and a 1 week nTargetTimespan:

Code:

//
// minimum amount of work that could possibly be required nTime after
// minimum proof-of-work required was nBase
//
unsigned int ComputeMinWork(unsigned int nBase, int64 nTime)
{
    return ComputeMaxBits(bnProofOfWorkLimit, nBase, nTime);
}

Code:

//
// maximum nBits value could possible be required nTime after
//
unsigned int ComputeMaxBits(CBigNum bnTargetLimit, unsigned int nBase, int64 nTime)
{
    CBigNum bnResult;
    bnResult.SetCompact(nBase);
    bnResult *= 2;
    while (nTime > 0 && bnResult < bnTargetLimit)
    {
        // Maximum 200% adjustment per day...
        bnResult *= 2;
        nTime -= 24 * 60 * 60;
    }
    if (bnResult > bnTargetLimit)
        bnResult = bnTargetLimit;
    return bnResult.GetCompact();
}

this is all great news , my advice is that the time to Fork is now , when the Currency is off exchange and theoretically  the lowest number of people are using clients.

also reinstating and a Hardfork causing an issue could have bad effects, so to do it here in the "shade" would be smarter, just my opinion , i don't own a lot of Caps at this time.

this has been quite educational .

[mullick]

I completely agree. If i do roll in the fixes to the stake system now it will take a bit more time. It is not necessary right now so I may do it at a later date. I would set the switch out plenty of time in advance so users would likely not notice.

It would take me a little time as i am still getting familiar with bitcoin coding. It is quite unique.

Say you have an application and want to change a major function. You change it and release a new update BAM its fixed. Bitcoin is special as you have to work around and delay they switch which is still quite new to me. Im learning fast and more every day

[Balthazar]

Fixed client is ready and works fine. I'll publish a pull request after having a dinner.

[mullick]

Fixed client is ready and works fine. I'll publish a pull request after having a dinner.

This guy deserves a cake^^^ Whos buying?

[DrGoose]

Thanks. I also prefer that all the major changes/fixes to be done (and a bit time tested) while we are not on Cryptys/coinchoose and such... should be better to come back with a single solid 1.5 upgrade than "bothering" a larger crowd with multiple smaller upgrades.

Less upgrades -> Less confusion -> more confidence into the coin -> higher value -> me happy.

One way or another, I am very thankful to mullick and balthazar (and others if any) for the hard work on this issue.

[Balthazar]

https://github.com/bottlecaps-foundation/bottlecaps/pull/4

No hard-fork required to resolve this. But you need to delete the blockchain files and download it again, otherwise you can get a problem.

[Lauda]

Thanks. I also prefer that all the major changes/fixes to be done (and a bit time tested) while we are not on Cryptys/coinchoose and such... should be better to come back with a single solid 1.5 upgrade then "bothering" a larger crowd with multiple smaller upgrades.

Less upgrades -> Less confusion -> more confidence into the coin -> higher value -> me happy.

One way or another, I am very thankful to mullick and balthazar (and others if any) for the hard work on this issue.

I must kind of agree to this right now aswell.
I think that it would be beneficial to push more things into this update right now, there are less people checking up on caps, less clients and so on. We have some time I think. 

[DrGoose]

Fixed client is ready and works fine. I'll publish a pull request after having a dinner.

This guy deserves a cake^^^ Whos buying?

0.25 BTC on the way to Balthazar for the cake... may be someone else would like to buy the beer or coffee?

[mullick]

Ok great! Pull request is merged in

For now here is the plan. Ill include the small tx value stake fix for now set to take effect in 1 week since most if not all users will update to the new fix.

As far as the other plans. I can set them i n to take place far enough in the future that users will likely not notice anything when it comes around. Due to the PoS difficulty being low still I will need to add checkpoints every 10 days to keep the network secure as the difficulty rises.

So i see no isse with releasing these fixes and getting us back live on cryptsy here soon. I will set the other update to 30 days out from the release of the client including the fix. That way you will have 30 days to update and have to miss 3 clients for you to be left behind.

If you guys see any issue with this let me know. But the changes will likely go off unnoticed and no special updates will be required as the checkpoints will keep you updating for the time being anyways. These other changes are not effecting the network right now they are just to ensure security in the long run.

Give me 1 hour for the next release

[Entz]

Good job guys

[Balthazar]

Ok great! Pull request is merged in

Just sent another one...

Due to the PoS difficulty being low still I will need to add checkpoints every 10 days to keep the network secure as the difficulty rises.

Pretty ugly solution. Just use centralized checkpoints, and you no longer will need to do something like adding 100500+ records into checkpoints.cpp.

[jdebunt]

grabbed the upgrade, wallet is syncing as we speak

[mullick]

Ok great! Pull request is merged in

Just sent another one...

Due to the PoS difficulty being low still I will need to add checkpoints every 10 days to keep the network secure as the difficulty rises.

Pretty ugly solution. Just use centralized checkpoints, and you no longer will need to do something like adding 100500+ records into checkpoints.cpp.

The massive wall of checkpoints was to help assist with syncing. As they would start down the wrong chain and have to restart to correct it. It got ugly and  I was planning on cleaning them up and doing a release pending the fix as those chains are no longer being broadcast. But you are too fast

Centralized checkpoints will be my preferred method from now on next release up

[mullick]

grabbed the upgrade, wallet is syncing as we speak

Not quite finished yet have to merge the other request and add a few more things. 20 minutes approx.