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

[Spoetnik]

* New windows installer.exe which will install a pre configured .conf file with all dedicated nodes we have setup

You gotta be careful with this so the installer won't mess up user settings like rpcuser, rpcpassword, rpcallowip, rpcport, etc. Also, don't forget that XP and 7 use a different directory path for user settings. Personally, I'm against installers making any changes to my configuration files.

Thank you I will include a warning for the installers. There will be separate installers for XP and Vista/7/8 and of course these will be optional there will always we a stand alone QT provided

You might try testing for the existence of an config file; if found, then rename it (.conf.old or .conf.org) so the user can copy any personal settings from it to your new file (if they have personal settings, they should be savi enough to manage that on their own)...

ya good idea..

nice coin dev work, nice to see you care and i hope you didn't go too crazy lol

[ISAWHIM]

Also note... some of us use a custom config file... (not named with the same name as a standard config. Set in the shortcut or bat file launchers we made.)

Forks are common in all coins. There is nothing you can do to fix that, unless you remove the whole nature of block-creation being on a single decentralized network. That happens by poor design from the original code. Adapting to the forks is all you can actually offer as a "fix". (Disconnecting and attempting to reconnect on a correct one. But that is a luck-shot, unless you have a centralized component to track the "one chain".)

Looking at all the other coins, this coin has "fixed" the issues faster than most, and had the least issues. Changing the diff will not matter. Finding blocks is still a lotto. When the diff rises, there are less forks, simply because there is more time between lotto-winnings among multiple computers. (The blocks have more time to propagate, and there is less chance to get two fast 300K high-diff blocks than there is to get two fast 100K blocks. It will still happen, even if the diff is 100M... Because every new block is a new lotto-drawing. Anyone can win twice in a row at any diff. That, and networks are not persistent, as much as we like to think they are. Whole trunks sever for minutes each day. That is where a centralized component helps. The net re-routs faster than all these private connections, which are a lower priority.)

Can't wait for the 1.4.1 update.

P.S. You could possibly reduce forks if you reject submissions sent less than 30-seconds of the last found block. Not accepting them as valid if any chain holds one without that 30-second gap. Resubmitting should be acceptable, or simply holding the solution until 30-seconds past the last found block, before accepting it, to build off of. Our miners will just keep looking for a better solution, while it attempts to resubmit the previously found one, until it is accepted or rejected.

[Choadmeyer]

Having a block chain issue....

Using v 1.4 but my block chain gets stuck EVERY time I run my wallet.

"Checkpoint is too old. Redownload Blockchain. If warning persists contact Development team."

Only option thus far that works is to delete and re-download the entire block chain, which is frustrating to say the least.

Can't wait for 1.4.1 or 1.5   

[BitJohn]

Having a block chain issue....

Using v 1.4 but my block chain gets stuck EVERY time I run my wallet.

"Checkpoint is too old. Redownload Blockchain. If warning persists contact Development team."

Only option thus far that works is to delete and re-download the entire block chain, which is frustrating to say the least.

Can't wait for 1.4.1 or 1.5   

That is just a checkpoint warning its fine normal on PoS coins

[Pmalek]

When is Epool gonna be online? And what will happen with mined coins there?

[ISAWHIM]

Mini fork detected... +3 blocks over, compared to coinchoose.

Coinchoose: 70309
Me 7-connections: 70312

Hit an ugly spot where I got 19 rejects... (Not all in a row, but I assume it was from coin-hoppers, which is all good.)

Last block I got was at 8:11 PM (GMT -5) {20:11}. Due for one now, but I suspect it will orphan, which is odd, since I am on the taller chain. Unless a client on the chain is simply rejecting all our blocks, trying to out-build us.


EDIT: NVM, coinchoose caught-up... one block behind, so that might just be a delay now. Fork-attempt failure. lol. I love how resilient this coin is.

Time to give my machines a break for the month anyways... Let them settle-down and cool-off for a bit.

[John Eden]

Bottlecaps now accepted on coingas.com and coming soon on http://jaysjerkyandgoodies.com/

email Jay at Jaysjerky@live.com and request your CAP's order for jerky now.

[BitJohn]

Bottlecaps now accepted on coingas.com and coming soon on http://jaysjerkyandgoodies.com/

email Jay at Jaysjerky@live.com and request your CAP's order for jerky now.

sweet!

[lazlopanaflex]

ETA for the wallet crashing fix? Kinda hard to buy stuff when one can't even transfer coins...

[GoldBit89]

still no 1.4.1 yet?

[John Eden]

Slight delay we expect very soon.

[lazlopanaflex]

Uh huh. A fix was supposed to be released two days ago per mullick. No offense, but there's not a lot of incentive to mine this coin when there's others out there that don't have wallet issues.

[flound1129]

Any update on the new client?

[Lauda]

Nice, now accepted in stores 

[flound1129]

Bottlecaps forked?  Coinchoose is reporting 1.275 diff, my pool has 0.46, block explorer has 1.232

[mullick]

Bottlecaps forked?  Coinchoose is reporting 1.275 diff, my pool has 0.46, block explorer has 1.232

Nope network intact. The webooise explorer stops updating every once in a while and thats the api coinchoose uses.

I see your block count is almost 30k behind. You must have found the bad chain again when you restarted. Im guessing you have very few or just 1 connection?

Redownload chain and restart with

listen=1
addnode=199.180.115.100
addnode=50.137.233.14
addnode=54.232.197.215
addnode=54.221.200.186

I have been doing lots of testing on the new client. Sorry for thee delay but im not about to release untested code. Hoping to have it done tomorrow. Network appears to be stable

The problem is with the difficulty algo. When a fork happens on a coin with a standard retarget every x amount of blocks the forked chain dies fast. As the hashrate moves away and no more blocks are found by the few remaining.

But with caps difficulty algorithm a few hundred KH is all thats required to keep the chain moving. and the slower people move to the correct chain the faster it drops as they are still finding block which drop the difficulty 10%+ each

Good for sites like coinchoose as they dont leave the chain stranded when they leave. But bad in a situation like this. That one forked chain just wont die.

That is why drastic changes are needed in 1.4.1 and I wont release until I am posotive it will do what I want

[flound1129]

Bottlecaps forked?  Coinchoose is reporting 1.275 diff, my pool has 0.46, block explorer has 1.232

Nope network intact. The webooise explorer stops updating every once in a while and thats the api coinchoose uses.

I see your block count is almost 30k behind. You must have found the bad chain again when you restarted. Im guessing you have very few or just 1 connection?

Redownload chain and restart with

listen=1
addnode=199.180.115.100
addnode=50.137.233.14
addnode=54.232.197.215
addnode=54.221.200.186

I have been doing lots of testing on the new client. Sorry for thee delay but im not about to release untested code. Hoping to have it done tomorrow. Network appears to be stable

Nope I have 23 connections. The stuff under pool stats is wrong, I'm at block 71921.

$ bottlecapsd getpeerinfo|grep addr|wc -l
23
$ bottlecapsd getpeerinfo|grep addr
        "addr" : "199.180.115.100:64480",
        "addr" : "70.98.114.237:43909",
        "addr" : "70.27.70.224:54674",
        "addr" : "50.137.233.14:53243",
        "addr" : "68.115.163.162:54551",
        "addr" : "76.110.255.33:62841",
        "addr" : "24.71.137.254:60082",
        "addr" : "72.202.148.137:49660",
        "addr" : "64.251.188.62:57625",
        "addr" : "50.2.8.67:34206",
        "addr" : "184.166.242.244:52371",
        "addr" : "50.149.211.203:52865",
        "addr" : "76.11.149.208:55060",
        "addr" : "91.109.5.247:55664",
        "addr" : "70.79.24.157:50460",
        "addr" : "71.46.67.79:62541",
        "addr" : "86.162.196.60:46728",
        "addr" : "107.217.208.215:58003",
        "addr" : "24.177.66.222:53068",
        "addr" : "68.81.64.95:53009",
        "addr" : "4.30.96.132:57798",
        "addr" : "89.168.3.49:56523",
        "addr" : "115.76.11.1:57774",

[digitalindustry]

Bottlecaps forked?  Coinchoose is reporting 1.275 diff, my pool has 0.46, block explorer has 1.232

Nope network intact. The webooise explorer stops updating every once in a while and thats the api coinchoose uses.

I see your block count is almost 30k behind. You must have found the bad chain again when you restarted. Im guessing you have very few or just 1 connection?

Redownload chain and restart with

listen=1
addnode=199.180.115.100
addnode=50.137.233.14
addnode=54.232.197.215
addnode=54.221.200.186

I have been doing lots of testing on the new client. Sorry for thee delay but im not about to release untested code. Hoping to have it done tomorrow. Network appears to be stable

The problem is with the difficulty algo. When a fork happens on a coin with a standard retarget every x amount of blocks the forked chain dies fast. As the hashrate moves away and no more blocks are found by the few remaining.

But with caps difficulty algorithm a few hundred KH is all thats required to keep the chain moving. and the slower people move to the correct chain the faster it drops as they are still finding block which drop the difficulty 10%+ each

Good for sites like coinchoose as they dont leave the chain stranded when they leave. But bad in a situation like this. That one forked chain just wont die.

That is why drastic changes are needed in 1.4.1 and I wont release until I am posotive it will do what I want

Ah this is what I half expected , although my post on this topic was maybe taken the wrong way at the time,  this is what I was trying to discover , interesting is it not , the trade off of adjustment to other effects .

[mullick]

All my nodes are on that chain as well. It appeared as thought the network was intact because all my nodes, both block explorers and the only pool in operation are all on the same chain.

This appears to be a whole other beast. All theorys about it being network communication are out the window. 23 connections on one chain 29 on the other

Occurred at block 71897 a PoS block. It appears half the network accepted it and the other half didnt.



ProcessBlock: ACCEPTED
received block 0000000077346f539791
SetBestChain: new best=0000000077346f539791  height=71894  trust=3171643634  date=08/13/13 03:56:24
ProcessBlock: ACCEPTED
received block 000000001b51fe0cc2b9
SetBestChain: new best=000000001b51fe0cc2b9  height=71895  trust=3171643635  date=08/13/13 03:56:29
ProcessBlock: ACCEPTED
received block 0000000057f1338b9272
SetBestChain: new best=0000000057f1338b9272  height=71896  trust=3171643636  date=08/13/13 03:57:14
ProcessBlock: ACCEPTED
received block 2c5744b9101da431f221
SetBestChain: new best=2c5744b9101da431f221  height=71897  trust=3188421108  date=08/13/13 03:58:06


I understand people will lose faith because this happened again.  I assure you I am working tirelessly to get to the bottom of it. I am a volunteer who picked this project up.  I have never been paid 1 cent for any work. I am doing this to fix what I believe to be a great coin. Fair launch, great community ect.

The issues appear to have been present before I took over. As checkpoints were all that was added in the release 11 days prior to the first incident.

Whatever the cause it appears drastic changes will need to be made. It may be a flaw in the stake system.

As a temporary measure to prevent these issues everyone please set:

reservebalance=1000000

In your .conf file. This will prevent PoS blocks from being generated until the issue can be resolved. Unless you have more than 1 million coins

I will need a debug log from anyone on the longer chain. Which appears to be mainly verns pool which is finding the blocks as once again 90%+ of the hashpower is contained there since currently it is one of 2 pools in operation.

More updates to come soon. Whichever chain contains the most miners/ coins will be chosen as usual


No changes to stake whatsoever have been made.

[mullick]

New info:

Both versions of block 71897 were found at exactly 3:58:06

Half the network accepted the PoS block and half accepted the PoW block