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

Have no idea....I was definitly on the"right chain earlier"....closed my wallet.....opened my wallet with port forwarding jumped from 8 to 45 nodes and ended up with a different number of blocks then what is showing at http://bottlecaps.kicks-ass.net/block_crawler.php.

It seems as soon as I allow more nodes to connect I'm screwed.

What's the current block height on the right chain? http://cap.coinmine.pl is currently on 78522. Is that correct?

If someone wants to upload that somewhere that has no reference to mega in it's name, I would greatly appreciate it. I refuse to even consider touching mega with a barge pole.

At work currently. The archive below will get you synced to the correct chain up to block 78500 roughly. Peers list has been cleared from all nodes. Once you are on the right chain you should stay now

https://mega.co.nz/#!Ud02GZTZ!ScpN8gc-YB5EFqUpOKATmhl3bCUGLv1Zf9uH8ip-PvM

After re-downloading the chain four times, connected to only nodes with the longer chain, it still connects to other nodes with the forked chain and downloads that one instead, and then ignores the longer one. I recommend everyone dump this coin, it's worthless.

The list I am using is right from the block-chain explorer list of connections...
http://bottlecaps.kicks-ass.net/block_crawler.php
http://bottlecaps.kicks-ass.net/peers.php

The peers list...

YES... finally... fifth time's a charm! (Got it again. But It will be lost again, I assume. I have lost the chain five times so far.)

I still only have 1 to 2 connections... which is what is causing the splits, I am sure... we keep branching if we all only have one or two other connections to talk to, and we can't communicate to one another.

Are you sure someone didn't change an IRC relay room to chr-code UTF-8 or something, instead of an (ISO-8859-1) standard format? Or could it be buggin on the ipv6 formatted IP's, trying to relay those to computers that just can't connect to them.

I need some sleep before work... my head hurts.

Well often enough it was from one of the lists posted or from the OP. Who knows how many forks there have been now. Some most likely ended quick when vigilant miners jumped off them right away (if I suddenly dropped to a few nodes I would bail out and reload the block chain). I'm looking forward to seeing how things work out over the next 24 to 48 hours.

It seemed though sometimes it was hard to get back on the right chain without opening and closing the client multiple times. As if it would reach a point where my connections were giving conflicting information (chains) so it would just stop loading.

That is the funny thing... this list is the list from the correct chain. But they are all giving me 78280 as the height, but I can see them at the height of 78415...

Like I said before, they are mining away and not telling anyone what they are building. They are isolating themselves from us, and feeding us the wrong block-heights. (I assume it is an array issue or something like that now. Are you using arrays that start at 0 but sending us 1-x not 0-x... or they are just sending corrupted data that can't be used?)

They tell us, "hey I am at block 78415", then we say, "great, send it!", then they say "Screw you, this is my block-list, get your own!", and kill our connection. Leaving us talking to the guy building his own chain which is shorter and 300 blocks behind. (Dramatic explanation. lol)

That has been my warning sign all along watch the connections and if they started dropping out it would turn out I was on the wrong chain.

That was odd... I had three good connections... Then, I unlocked my wallet and they all disappeared and it took a connection with a starting height that was 2000 lower than the newest fork.

(The chain I was on, with that ipv6 connection forked and everyone started dropping-off and now I am seeing more "-1" start-heights on the version 70000 client 1.4.1.)

Funny thing is... the peers sending the wrong blocks are in the list of peers connected to the chain with the correct height...

I am getting -1 from about 12 on the 25 in the list, and everything from 75000 to 76000 to 77000 to 78000 from them. They are all version 1.4.1 (70000)

IP: 188.252.16.109

reports as -1 block-height, and it is the one that the wallet keeps connecting to, over and over.

Huh I haven't seen that in a peers file before. Kinda neat i guess its not special but interesting to see one. Wonder if the UPNP will help open up more connections as well we shall see as the chain gets healthy again.

The code has a timestamp of 1376758800 which is 17:00 GMT and as EST is currently GMT-4 (Daylight savings) it actually kicks in at 13:00 EST, not 12:00 EST.

Also you won't necessarily drop them, if you're already connected to them and they're not deemed as misbehaving (same chain as you) you'll likely stay connected to them unless you restart your client after the deadline. Peers who continue to use the old version will run out of peers using v1.4.1 soon enough though and they'll likely end up on their very own unsupported fork.

Is it to the point where we should be dropping the old clients now?

ISAWHIM you mentioned a limit of 8 connections. While resyncing this morning I showed 13 or 14 connections and then when I hit block 78000 or so it dropped to 2 connections.

Currently I am bouncing between 2 and 3 connections and do not understand why I cannot get more. I am soloing and keeping a close eye on it.

Edit: can't type

Just got an odd ipv6 addr... (2001:0:5ef5:79fd:1cd3:64c:add1:6b8c)

[
{
"addr" : "92.5.104.42:7685",
"services" : "00000001",
"lastsend" : 1376751282,
"lastrecv" : 1376751280,
"conntime" : 1376744432,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78102,
"banscore" : 0
},
{
"addr" : "50.137.233.14:7685",
"services" : "00000001",
"lastsend" : 1376751281,
"lastrecv" : 1376751280,
"conntime" : 1376745877,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78125,
"banscore" : 0
},
{
"addr" : "115.76.11.1:7685",
"services" : "00000001",
"lastsend" : 1376751281,
"lastrecv" : 1376751280,
"conntime" : 1376746046,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78127,
"banscore" : 0
},
{
"addr" : "[2001:0:5ef5:79fd:1cd3:64c:add1:6b8c]:7685",
"services" : "00000001",
"lastsend" : 1376751281,
"lastrecv" : 1376751280,
"conntime" : 1376750607,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 78205,
"banscore" : 0
}
]

Seems to be connecting fine to it... and it has the correct height, for the moment. Not all IPV4's can actually connect to IPV6 though. Lucky me, my ISP and router auto-convert. Since my ISP's modem doesn't actually have IPv6 ability.

I shouldn't have to, it should just connect and download the longer chain. It's connected to several peers with it, so there's no reason why it shouldn't, except that either they didn't actually test it before releasing it and bugs creeped in, or they are just incompetent...

You might just want to wait until after noon, when the old versions are kicked and the new versions are the only ones mining.

Then, sadly... redownload the whole DB again, deleting everything except your config file and your wallet.dat...

Once you hit block 72000, stop the client/wallet... wait for it to actually die... and save everything it created, except the config and wallet... into a folder called "backup". Then, if you do get on the wrong chain... (let it try and try... you may get the wrong one at first, but it should eventually hit the correct one... if it does not, then just delete what it downloaded, and paste your backup data back into your wallet folder, so you start again from 72000.)

Eventually one of these connections will lock and begin working for you. (I hope.)

Or mine on a pool that is working... (The easier option, until the connection issue is resolved.)

It's pissing me off that I'm connected to several peers with the right chain, the 78k+ one, but it flat out refuses to download or even acknowledge that that is the right chain. On top of that this stupid forum gave me a database error when posting, so I had to wait 15 minutes between posts because it thought I posted.........


EDIT: This is seriously pushing me away from this coin. How hard is it to code it so that the client recognizes that the longer chain is gthe proper one, and to sync to that one? Too hard I guess...

I'm also loving how it crashes every time I exit it.

Did you restart the client... if it hangs, it will not continue until you shut down the client and restart again. Don't delete your blocks data if you are that far... it just hung on a bad send. (I had to do that multiple times, to get the last 200+ blocks)

The wallet never reported the final height once... until I hit a POS block... that refreshed the screen. Then it showed I was up to date... the whole time I was actually up to date, but the wallet just didn't display I was, when I actually was.

Unlock it, and try mining... if you start mining, then you are up to date, if you see one correct height in your list of peers.

78197 current height (CGminer reported diff 79-83K... if you see less, you are not on the right chain.)

That missing 100 blocks should be resend in matter of minutes, it is over hour and I`m still on "blocks" : 77977
Something is not right IMO.

That is all you need... the heights are the heights when they first connected... they will not update the start-heights, unless they disconnect and reconnect to you, after getting the missing blocks. Then you see the new heights.

What you don't want to see is this... (corrupted or NULL or invalid or cut/trimmed packet data)

 "addr" : "95.72.68.42:29670",
        "services" : "00000000",
        "lastsend" : 0,
        "lastrecv" : 0,
        "conntime" : 1376748399,
        "version" : 70000,
        "subver" : "",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : -1,

or connections to older versions 60001, 60002, 60003