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

[BitJohn]

Ok I stand corrected seems the two block explorers are disagreeing hopefully the devs push out the fix shortly.

[1713573802]

1713573802

[1713573802]

1713573802

[1713573802]

1713573802

[chondrite]

P.S. Exchanges might want to halt delivery and acceptance for a while, until they figure out why the programs they are running, are isolating themselves from others on the network. You will be exchanging coins that are going to disappear soon.

Hard-coding blocks from those exchanges, on a network that is constantly isolating itself will NOT help.

Mining on the high diff chains will only work if you keep constant miners on there. Once they leave, the new miners will be connecting to the chain that is actually talking, the ones that you connect to without addnodes and the ones that are on the original addnodes listed on the front page.

Though, since the change, those four listed are not sending the block-chain to us, only telling us that they have a bigger block-height. Which is just useless if you want your chain to grow. It can't grow if you don't tell us what to build off of.

My personal wallet, the exchange, the block explorers don't seem to have an issue staying on the correct chain and the update is right around the corner.

I have these peers connected and all at the right height:
addnode= 192.241.222.16
addnode= 70.79.24.157
addnode= 70.98.114.237

This list of addnodes put me on the same chain as you, bottlecapspool, and cryptsy.  Thank you.  Everyone should note these are different than those posted in the OP.  Probably whats causing the issue.

[butjust41day]

Sounds a lot like what was happening to me the other night. Re-downloading the blockchain multiple times with what were suppose to be the "trusted nodes" and then ending up on the wrong chain. With the assumption by others that I was somehow doing it wrong.

The next day I was finally able to download the correct chain with connect= (some node that was at one time posted in OP). The night before that node seemed to be down.

What I found really odd was that half of the blocks I had expected to be lost since I was on the wrong chain were confirmed in my wallet. Don't have the technical expertise here to explain that; but, it almost seemed as if I had mined blocks on both chains (doubt that is possible yet I can't explain it).

[Lauda]

Problems again 

[mullick]

The problem with the "trusted" nodes is they themselves were moved to the wrong chain. I have removed them from the OP for now until they get on the right chain.

Thanks to a wonderful bit of knowledge from Sunny King I believe I have nailed down the issue

Once I am confident I have made the changes I will release a statement with the cause/ fix and all info pertaining to it.

For now Pertfiied has put up a list of nodes on the current chain. Redownloading the chain with those as addnodes should get you on the right chain ( which is the longer of the two ). If not connect= any of those nodes should get you directly connected to it and download the chain from them.

I will be working furiously to get the update pushed out tonight. Hopefully we can leave all these issues behind us

If your blockcount is matching the one below you are on the right chain

http://bottlecaps.kicks-ass.net/block_crawler.php

[Pmalek]

GREAT WORK MAN! I love this coin! 

[braytz]

Problems again 

+1 i can't sync my wallet correctly with the OP's nodes.

[Vivisector999]

I am trying a small store for a few Bottlecaps items/  Right now accepting Bottlecaps and LTC.   

Currently dealing in World of Tanks gifts and iTunes cards.  Other options will be added as I find them (Steam Codes, possibly other Gift cards and MMO game items)

http://bottlecapstore.weebly.com/


Will buy a different address once I figure out the perfect name for it.

[ISAWHIM]

Here is what is happening to my wallet... This is the reason many of us can not connect...

That long list of connections (I assume all linux compiles)...
Are all feeding this to us... (windows compiles v1.4.0)
{
"addr" : "199.192.205.46",
"services" : "00000000",
"lastsend" : 0,
"lastrecv" : 0,
"conntime" : 1376446605,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}


That is one of the connections, and they are all doing that, all IP's listed below, without xxxx's... from the list on the block-explorer... It connects for a split second, which is how I captured that info, then instantly disconnects us.

Notice VERSION: 0 and STARTINGHEIGHT: -1 and SERVICES: 0 and SUBVER: "", all null I assume, except the block, which may be null -1.

All connections are killing us, or we are killing all these connections...

We can't download the chain, because there are -1 blocks to download. (They are not speaking to us. Us windows users, I assume. WG, the windows compile is screwed-up. We connect fine when we are all on the same chain, win/linux... But now the correct chain seems to be only on linux, and it is not speaking to windows wallets. Check your "terminators"... windows is CRLF not just CR or LF, like linux or mac. Or the linux compiles are all botched, and not accepting windows data.)

These are the only ones speaking to us... (Even when we add the big list from the block-chains.)
[
{
"addr" : "70.98.114.237:7685",
"services" : "00000001",
"lastsend" : 1376447163,
"lastrecv" : 1376447164,
"conntime" : 1376447105,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "192.241.222.16:7685",
"services" : "00000001",
"lastsend" : 1376447118,
"lastrecv" : 1376447121,
"conntime" : 1376447117,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "199.180.115.100:7685",
"services" : "00000001",
"lastsend" : 1376447132,
"lastrecv" : 1376447133,
"conntime" : 1376447130,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "70.79.24.157:7685",
"services" : "00000001",
"lastsend" : 1376447348,
"lastrecv" : 1376447378,
"conntime" : 1376447343,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72116,
"banscore" : 0
}
]

Get one of those with the correct height, and we will all be in sync again...

NOTE: I have removed them from my list, and deleted peers, and the block-chain files... they always keep reconnecting to these four IP's...

Below is the long list (I have it setup to 100 connections, but the wallets only allow 8.) None connect, except the ones I xxxxxx'ed out... Which all have a block-height of 72115 now.

splash=0
server=1
gen=0
testnet=0
daemon=1
maxconnections=100
listen=1
xxxxxxxxxxxxxxxreservebalance=1000000

addnode=2.81.165.221
addnode=5.167.120.71
addnode=24.177.66.222
addnode=46.4.74.197
addnode=50.137.233.14
addnode=54.232.197.215
addnode=60.242.225.227
addnode=69.85.86.195
addnode=70.69.238.84
xxxxxxxxxxxxxxxxxxxxxxxaddnode=70.79.24.157
addnode=70.98.114.229
xxxxxxxxxxxxxxxxxxxxxxxaddnode=70.98.114.237
addnode=72.190.53.101
addnode=80.198.94.98
addnode=82.46.148.115
addnode=82.196.15.206
addnode=88.195.204.114
addnode=91.78.85.221
addnode=92.5.104.42
addnode=92.24.172.199
addnode=95.25.114.165
addnode=105.236.213.165
addnode=106.186.30.13
addnode=106.186.115.58
addnode=106.187.100.78
addnode=108.16.165.144
addnode=114.198.5.175
addnode=172.250.241.106
addnode=174.52.220.23
addnode=176.34.210.88
addnode=183.235.214.148
addnode=186.95.162.209
addnode=188.165.194.201
addnode=188.165.211.65
addnode=190.19.238.43
addnode=192.241.148.204
addnode=192.241.216.151
xxxxxxxxxxxxxxxxxxxxxxxxaddnode=192.241.222.16
addnode=192.241.222.102
addnode=199.192.205.46
xxxxxxxxxxxxxxxxxxxxxxxxaddnode=199.180.115.100
addnode=199.180.115.125
addnode=208.54.70.131
addnode=213.141.109.154

[Vivisector999]

Weird, here are the ones I have, totally different:

{
"addr" : "50.2.8.67:7685",
"services" : "00000001",
"lastsend" : 1376448358,
"lastrecv" : 1376448358,
"conntime" : 1376447942,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73204,
"banscore" : 0
},
{
"addr" : "106.187.100.78:7685",
"services" : "00000001",
"lastsend" : 1376448358,
"lastrecv" : 1376448358,
"conntime" : 1376447954,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73204,
"banscore" : 0
},
{
"addr" : "92.5.104.42:7685",
"services" : "00000001",
"lastsend" : 1376448359,
"lastrecv" : 1376448359,
"conntime" : 1376447955,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73204,
"banscore" : 0
},
{
"addr" : "80.198.94.98:7685",
"services" : "00000001",
"lastsend" : 1376448358,
"lastrecv" : 1376448358,
"conntime" : 1376447999,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73204,
"banscore" : 0
}
]

Hope I am on the right chain???

[ISAWHIM]

"startingheight" : 73204

Seems like the right height...

I assume you are not using the windows compiled wallet v1.4.0...

PM me, and I will send the log-file of a fresh connection to that list... From my windows client. It shows every connection connecting, then terminating, over and over, entering and exiting rooms, looking for connections which are in that list, and others. All with the same results.

[Entz]

Odd, I launched a new windows wallet this afternoon and it is having no issues syncing? Not sure if it is the right chain or not (will send a cap from my linux wallet to confirm)

Code:

20:06:42

[
{
"addr" : "70.98.114.229:7685",
"services" : "00000001",
"lastsend" : 1376449594,
"lastrecv" : 1376449594,
"conntime" : 1376449251,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73225,
"banscore" : 0
},
{
"addr" : "80.198.94.98:7685",
"services" : "00000001",
"lastsend" : 1376449595,
"lastrecv" : 1376449595,
"conntime" : 1376449264,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73226,
"banscore" : 0
},
{
"addr" : "78.31.105.38:7685",
"services" : "00000001",
"lastsend" : 1376449571,
"lastrecv" : 1376449594,
"conntime" : 1376449264,
"version" : 60006,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73226,
"banscore" : 0
},
{
"addr" : "92.5.104.42:7685",
"services" : "00000001",
"lastsend" : 1376449595,
"lastrecv" : 1376449594,
"conntime" : 1376449265,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 73226,
"banscore" : 0
}
]

edit: Yes, windows-qt and linux-qt are on the same chain.

[ISAWHIM]

What version of windows? (Mine is Win-7 home 64-bit.)

Also, are you using the v1.4.0 version? If yes, do you remember which link? (One of the links might have screwed-up compile settings. Like optimization and removal of error-checking or out-of-bounds checking.)

[Entz]

Windows 7 pro 64-bit
wallet is the latest one posted in the original message of this thread. v1.4.0.0-g32a928e-caps

[ISAWHIM]

Windows 7 pro 64-bit
wallet is the latest one posted in the original message of this thread. v1.4.0.0-g32a928e-caps

Same one as I have... but those connections are not working, the wallet is just going hyper disconnecting and joining tons of rooms, looking for more connections.

This is getting more strange with each day that passes. lol.

I am going to redownload both exe's and compare them. Though I doubt we are all corrupted, as others are still getting stuck on those four connections.

UPDATE: No luck... both still have the same results.

The only other thing I can think-of, is "home" does not offer language-packs, other than default. Is it possible someone in the chat-rooms is broadcasting ISO:Chrs that home users can't "translate", without having the language-packs. (If it is not a "terminator" issue, it may be a ISO:chr format issue.)

Win-home only has a few languages. Windows fails to convert other ISO standards, unless you get the ultimate or pro versions. (Similar things happen on japanese and chinese websites and programs.)

EDIT: I can think of one more issue... could my IP be rejected, from being listed with a banscore? IP's are not fixed, and mine rolls every few days. How do you check something like that? (If they are rejecting my connection, because of a banscore... I have no clue who had this IP before me. IP banning is as useless as cookie-banning. lol. It would be odd that I was IP-banned from every single correct chain, and IP, except the four with the wrong-height, which is the four I was mining on for weeks, without issue, and still connect to.)

[Vivisector999]

Yeah mine is Windows 7 - 64 Bit as well, with the latest download on the OP.  I did delete the blockchain and recreated the bottlecaps.conf file with the single IP address that was posted recently on the OP as well.


....
rpcport=8385
addnode=69.85.86.195
daemon=1
server=1
gen=0

[John Eden]

The 1.41 should be out very soon we are testing it right now to assure its working as planned. Sunny King assisted with the fix to PoS to ensure we have no issues in the future. This update will be required and block out the older clients causing issues.

We will release a detailed explanation of everything when the wallet release takes place. Thanks again for being patient ans supporting the coin!

[paulsltc123]

yeah..i'll just wait for the new client release cuz i'm having a nightmare of a time connecting the client to the correct chain. trying so many different addnodes or connects and on only a few it will at least show the correct block height but it never fully sync's all the way to it.. the ones that do sync are when i'm on the wrong chain that has the wrong (lower height)..i give up..so will wait for the new client

[GoldBit89]

Windows 7 pro 64-bit
wallet is the latest one posted in the original message of this thread. v1.4.0.0-g32a928e-caps

Same one as I have... but those connections are not working, the wallet is just going hyper disconnecting and joining tons of rooms, looking for more connections.

This is getting more strange with each day that passes. lol.

I am going to redownload both exe's and compare them. Though I doubt we are all corrupted, as others are still getting stuck on those four connections.

UPDATE: No luck... both still have the same results.

The only other thing I can think-of, is "home" does not offer language-packs, other than default. Is it possible someone in the chat-rooms is broadcasting ISO:Chrs that home users can't "translate", without having the language-packs. (If it is not a "terminator" issue, it may be a ISO:chr format issue.)

Win-home only has a few languages. Windows fails to convert other ISO standards, unless you get the ultimate or pro versions. (Similar things happen on japanese and chinese websites and programs.)

EDIT: I can think of one more issue... could my IP be rejected, from being listed with a banscore? IP's are not fixed, and mine rolls every few days. How do you check something like that? (If they are rejecting my connection, because of a banscore... I have no clue who had this IP before me. IP banning is as useless as cookie-banning. lol. It would be odd that I was IP-banned from every single correct chain, and IP, except the four with the wrong-height, which is the four I was mining on for weeks, without issue, and still connect to.)

check your debug log files and you can see what irc you connecting to and then check them to see if they have banned or put a temp hold on your ip.

[mullick]

I am now 99% certain I have found the issue. For this fix ALL clients will need to update AS SOON AS POSSIBLE.

As far as pool forks. This update also will resolve those issues as the real problem was contained in the QT. When PoS blocks were generated by a pool wallet it was rejected by the main chain and the pool went off on its own. As long as pool operators maintain plenty of connections to the network there will be NO MORE issues from this previous round.

Caps should be the only coin effected all other caps forks should be ok. Release will be tomorrow afternoon

* checkpoints
* stake fix
* UPNP enabled
* yet even more dedicated nodes
* possible disconnect of all old clients after 48 hours (TBD)

After 1 week of network stability 1.5 will be released with the 5% static stake reward


Breakdown of why the forks have occured

First fork:

This fork created many issues and it appeared to be multiple. The forked chain was kept alive for a very long time. older clients can still connect to this chain and mine at extremely low difficulty making it keep pace with the main correct chain.

It was caused by a lack of network communication and a lack of dedicated nodes. It appears the network "split" with each side only communicating with each otherlong enough to get the required 26 blocks to validate it as a correct chain. After this point the 2 chains were incompatible with each other.

One one side you had Multipool, bottlecapspool.com and cryptsy as well as some solo miners

On the other side you have most smaller pools and epools. As well as some solo miners as well

Pool forks:

Multiple times pools were "segregated" form the rest of the network and created their own chain. Each time it was only the pool effected maybe taking 1 or a few other peers with them.

This issue has been addressed and should not occur anymore as long as pool operators ensure they have a healthy number of connections to the network

Latest fork:

The issue was caused by a incompatibility with the windows qt and github sources. They had different "computeminwork" requirements. When PoS block #71897 was created the github compiled clients rejected the block while the windows qt accepted it. Causing 2 separate chains.

This issue has been cleared up and should not present itself again.

New client will be out as soon as I verify both clients are giving similar results again and I will be running tests overnight to ensure this. When I wake up and verify I will push the updates to github and compile the new QT from a fresh gitpull. It is imperative you update as soon as possible to prevent any issues from the change over. Once past this point it will be smooth sailing from here on out

Thank you Sunny King for your insight as well as ISAWHIM for further intriguing me to look into this as the possible cause

Once again the community has been amazingly helpfull and supportive.

We are in it for the long haul and hope these issues are finally behind us and we can move on with our planned development path