Topic: Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS - page 187. (Read 388610 times)

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

Nice, now accepted in stores 

Any update on the new client?

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.

Slight delay we expect very soon.

still no 1.4.1 yet?

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

sweet!

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

email Jay at [email protected] and request your CAP's order for jerky now.

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.

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

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

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   

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.

ya good idea..

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

Ill ask about that. I personally will not be doing the Windows installer. But will make sure the dev working on it takes a look

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

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

Proposed changes to 1.4.1 have been uploaded to the development branch on github for peer review.   https://github.com/bottlecaps-foundation/bottlecaps/tree/Development-Branch-(-Open-Testing-)

After much frustration and many possibilities reviewed Here is how I have decided to proceed with shaking the dodgy peers and forks which are still being kept alive with little hashrate due to the difficulty algorithm

1.4.1 Change log:

* added multiple checkpoint to get clients on the right path.
* added protocol changes to disconnect any client previous to 1.4.1 at block 77500 Approx. 7 days from when I coded the changes
* Added irc changes to create a new IRC channel at block 77500 when all outdated clients disconnect. Just in case
* New windows installer.exe which will install a pre configured .conf file with all dedicated nodes we have setup
* Not really a code change but setting up a total of 6 dedicated nodes Located in AUS,  South america, Canada, Bulgaria and USA to speed up and help blocks propagate between peers. All running close to 50 connections on high speed networks. Keep in mind some are not free. Any expenses for this will come out of the Foundations donation fund and our pockets since there was no pre / instamine


These changes may seem drastic but we cannot allow the network to continue functioning like this. This will be a Mandatory update once again. If you are not updated by block 77500 you will likely be left on a forked chain. As you will not be able to communicate with the rest of the network running version 1.4.1

This will get rid of all bad nodes we have been seeing recently throwing clients out of sync and preventing proper chain downloading

 Release is scheduled for 8/10/2013 around midnight forum time. Ensuring enough time for our nodes to gain connections and prove reliability. As well as giving the community time to review the changes. As I have been working on this for quite some time and may have gone nuts during the process. Although I believe all changes will take effect.

The changes updated to the development branch are in no way final as I have had no time to fully test or even compile a client. I will do this all in the morning and get the client released when I am finished. It is just more to give users an idea of changes to be implemented and gain feedback for a short time prior to release

We will be doing giveaways for users providing proof of the upgrade ect to make sure as many users are aware of the update and are not left behind at block 77500.

If all goes well and we can achieve 1 week of stability in the chain we will then continue with out previous development path located here

https://cryptocointalk.com/blog/7/entry-22-the-bottlecaps-foundation-30-day-user-update/

If you would like to setup a node please contact me with details and for any help setting up