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

[sigesang]

Yeah since debug is really useless..
The works are behind the scene. Will be pushed to github once ready I belive.

commited line starts with "+-", it just compiles by accident

How many times do I need to repeat myself?

It's not like u got anything else to do it seems ...

[mullick]

Nothing on git, I manually added some checkpoints using data from crawler.
It works last time, but network forks again and I stay in "bad" fork...
Downloading chain again, but this should not happen

https://github.com/bottlecaps-foundation/bottlecaps/commit/33f4cee4ec3b8c9e131dcb3f6f430424e8cdf732
Is the only recent change. Relax it's being worked on.

Looks like some random debug commit, that don't even belong in git history

I was working with another dev who suggested we print the questionable ntargettimespan to the log to verify it was being calculated the same accros all platforms.

I slipped it into github so if anyone compiled it and went off on the wrong chain I could verify that wasnt the issue.

Much more work has been done behind the scenes

As far as yesterdays fork all 5 of the machines I use including the 3 vps that host the nodes show no record of the block in question. Which is yet another good sign as in the past they as well have been pulled to the wrong chain

if you went to the other chain last night... How many connections were you averaging? All my nodes / wallets average 30 connections. It seems some peers have trouble achieving more than 10 connections and may be the reason they are the only ones effected. But it is not the cause of the issue just explains why few peers are experiencing it lately.

Both pools cap.coinmine.pl and multipool.us were not effected it seems

[ISAWHIM]

The best luck I have had, staying on the right chain is by doing this...

EDIT: (Also, using reservebalance=100000000 to stop POS from happening by my wallet.)

Took the list of connections from the block-crawler and changed 8 of the "addnode" to "connect". That gave me more than the normal 8 connections that I would seem to be limited to, if I just had all "addnode" links. Giving a total of 13-14 connections, as opposed to 8.

EG...
I turn this list... (Which normally only give me 8 connections.)
maxconnections=100
addnode=92.5.104.42
addnode=108.20.60.26
addnode=192.241.222.16
addnode=192.241.216.151
addnode=192.241.222.102
addnode=192.95.37.194
addnode=24.5.121.137
addnode=188.165.211.202
addnode=88.100.132.85
addnode=70.79.24.157
addnode=80.198.94.98
addnode=217.169.211.146
addnode=69.9.152.126
addnode=69.10.44.115
addnode=67.11.24.42
addnode=192.64.86.238
addnode=72.238.120.59
addnode=50.137.233.14

Into this... (Which gives me 13-14 connections.)
maxconnections=100
connect=92.5.104.42
connect=108.20.60.26
connect=192.241.222.16
connect=192.241.216.151
connect=192.241.222.102
connect=192.95.37.194
connect=24.5.121.137
connect=188.165.211.202
addnode=88.100.132.85
addnode=70.79.24.157
addnode=80.198.94.98
addnode=217.169.211.146
addnode=69.9.152.126
addnode=69.10.44.115
addnode=67.11.24.42
addnode=192.64.86.238
addnode=72.238.120.59
addnode=50.137.233.14

That is the only solution I have to those showing low connections. This trick should also work if you have high connections, and you should now see more than what you would see, if you only had "addnode" for your connection types.

However, even the "connects", eventually kill the connection, and I get left with only "addnode" links, which thus returns to 8 or less. At the time I noticed that the chain was not matching, I only had 6 connections left. Which took almost three days to happen.

Now, I started again with 13-14 connections, using the same trick above... But 12 hours later, I am down to 11 connections. So, I assume I have the 8 addnodes and lost 2-3 of the ones I forced to connect. They either left, changed IP's, disconnected from me for ??, decided to link another wallet instead of me, or are now mining on a private chain/fork...

So connections are still being rejected, for no apparent reason, causing the issues. Having more connections only delays what happens, and when it happens. The result is still the same. The constant severing of connections leads to isolation at some point, when the cross-thread-IP connections can no longer communicate with the largest hash-rate miners. (Those are the ones that eventually become the tallest chain, because they just find blocks faster than total of severed units that are still joined.)

[ISAWHIM]

Another wierd thing I noticed...

When the application froze, after trying to shut it down to delete the bad chain, and restore a known good backup, for rebuilding the correct chain... (Because, again, it saw the correct height, it just didn't do anything to "fix" the chain itself at that point. Rebuilding from the split, as one would assume it would do.)...

I had to go to taskmanager, which is not abnormal for the last 1.4.1 and 1.4.2 builds... and kill the app. However, there were three bottlecap-qt.exe's running in the taskmanager. There were not 3 when it was running normally. But I can not confirm if "trying to exit normally", caused the three instances... or if somehow while running, and losing connections...that 2 more instances just launched themselves? It was strange. (I will wait until it gets to that point again, and make some observations. However, I suspect that the "exit" function is screwy, causing the app to attempt to relaunch, in order to close itself or finish closing work, and just hanging in the process.)

[mullick]

Multipool.us has a substantial % of global hashrate. If you are mining there please consider switching to cap.coinmine.pl at least temporarily.

Both pools have been on the correct chain for almost 5 days now and have great operators

[braytz]

CAP on multipool is disabled

[mullick]

CAP on multipool is disabled

Dedicated pool has been up for about the last week. Thanks to Flound for keeping an eye on it. Currently about 30 Mh

https://www.multipool.us/stats.php?curr=cap

[rav3n_pl]

P2pool have ability to send blocks between nodes, this might help if we would have running at least few fully updated nodes that are mining.

[mullick]

P2pool have ability to send blocks between nodes, this might help if we would have running at least few fully updated nodes that are mining.

Yep i have not been uble to get the front page updated but as soon as I will it be emphasized

[Lauda]

A few more things in the works now  .

[bronan]

Well my client is now stuck for several weeks at 18042 remaining and does not move
It has about 12 connects but nothing changed i deleted also several times the old blockchain
Every time same at around 18000 to go and stops

[ISAWHIM]

Well my client is now stuck for several weeks at 18042 remaining and does not move
It has about 12 connects but nothing changed i deleted also several times the old blockchain
Every time same at around 18000 to go and stops

Make sure you have the line...

reservebalance=100000000

Inside of your config... If you are generating POS (Which can be done before the chain finishes syncing.) They may be cutting your connection because you are attempting to submit POS work while downloading, and you are getting severed from that issue, which is not fixed yet.

Just restart the client/wallet... don't keep deleting the database. The other clients are cutting you off, from data delivery or the data is getting corrupted from one packet (Thus, stopping that block from being added to the database). Restarting will cause it to drop that packet and continue from where it got the last good packet delivered.

Once you are sure you are at the correct height, stop the wallet/client, and backup everything except "peers.dat", "wallet.dat" and your config file. (You can optionally backup your wallet to another location, but don't restore it when you restore the database. Wallet backups should only be restored if you are in dire trouble, and your wallet somehow gets corrupted or damaged.)

Use those other files to restore the database if you "fall off the tall chain"... Because the wallet does not seem to have the ability to "fix" or rebuild the taller chain after you have gotten blocks from the shorter chain. (If it can, it does not do it within a reasonable time. I waited hours and it never fixed itself, though it could see the taller chain and see I was not synched.)

And the wallet doesn't seem to "archive" the "known good database", for easy restoring from that point forward.

Also try the connect thing a few posts up... using the list of connections from the block-crawler list of connections.

[DrGoose]

Was on the same chain as block crawler for ~5 days and I had >30 connections steady (as high as 43 sometimes).

I was even on the block crawler list all this time.

BUT

Woke up this morning and found there was a fork. I am now down to ~25 active connections and my getmininginfo differ from the block crawler. I am not on their list anymore.

How do I know which fork is "right"? Is the block crawler THE reference no matter what?


My getmininginfo @12:47:14
{
"blocks" : 90889,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.56681370,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 0,
"testnet" : false
}

Block Crawler at the same time
Block Count: 90,900
Block Reward: 10
Difficulty: 0.62017375
Connections: 25

[feeleep]

same happened to coinmine pool - redownloading once again...

[braytz]

so, are all the problems solved, or is there any fork? 

[feeleep]

same happened to coinmine pool - redownloading once again...

pool is back on track

[DrGoose]

Developers:
Is the block crawler THE reference no matter what ... or I should keep my wallet/chain running? I have now 23 connections to others.

Thanks.

Update: I did stop my solo mining and wallet and now redownloading the chain. I still would like to know if block crawler is THE reference no matter what. Thx.

===

getminigninfo @14:12:36
{
"blocks" : 90947,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.44385671,
"errors" : "",
"generate" : false,
"genproclimit" : -1,
"hashespersec" : 0,
"pooledtx" : 0,
"testnet" : false
}


getpeerinfo @14:12:37
[
{
"addr" : "192.241.222.102:34975",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1376919166,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 80960,
"banscore" : 0
},
{
"addr" : "192.241.216.151:60823",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377015948,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 82569,
"banscore" : 0
},
{
"addr" : "69.9.152.126:57233",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377288563,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 87027,
"banscore" : 0
},
{
"addr" : "192.64.86.238:7685",
"services" : "00000001",
"lastsend" : 1377526333,
"lastrecv" : 1377526332,
"conntime" : 1377330841,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 87785,
"banscore" : 0
},
{
"addr" : "198.144.156.122:52202",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377368671,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 88391,
"banscore" : 0
},
{
"addr" : "72.39.81.250:63772",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377372978,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 88441,
"banscore" : 0
},
{
"addr" : "91.235.254.37:35000",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377435243,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 89493,
"banscore" : 0
},
{
"addr" : "62.24.83.120:49454",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377459443,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 89898,
"banscore" : 0
},
{
"addr" : "80.229.2.127:60896",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526012,
"conntime" : 1377461997,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 89940,
"banscore" : 0
},
{
"addr" : "201.34.236.252:30338",
"services" : "00000001",
"lastsend" : 1377526335,
"lastrecv" : 1377526335,
"conntime" : 1377465040,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 89982,
"banscore" : 0
},
{
"addr" : "80.198.94.98:7685",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377476260,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 90178,
"banscore" : 0
},
{
"addr" : "162.197.248.49:62787",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377484148,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 89486,
"banscore" : 0
},
{
"addr" : "5.150.212.9:56021",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377484449,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90317,
"banscore" : 0
},
{
"addr" : "64.136.208.127:29381",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377490814,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90422,
"banscore" : 0
},
{
"addr" : "114.198.9.122:10425",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377499822,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90563,
"banscore" : 0
},
{
"addr" : "178.49.118.233:60592",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377509018,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90702,
"banscore" : 0
},
{
"addr" : "194.141.43.4:64284",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377510411,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90529,
"banscore" : 0
},
{
"addr" : "50.140.100.241:60453",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377516905,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90824,
"banscore" : 0
},
{
"addr" : "109.60.111.123:64269",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377522327,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90898,
"banscore" : 0
},
{
"addr" : "82.161.65.210:63128",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377523983,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 68696,
"banscore" : 0
},
{
"addr" : "87.183.14.3:51331",
"services" : "00000001",
"lastsend" : 1377526350,
"lastrecv" : 1377526349,
"conntime" : 1377525468,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 0,
"banscore" : 0
},
{
"addr" : "223.64.62.171:21877",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377525771,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90935,
"banscore" : 0
},
{
"addr" : "173.227.57.98:1147",
"services" : "00000001",
"lastsend" : 1377526332,
"lastrecv" : 1377526332,
"conntime" : 1377526182,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90944,
"banscore" : 0
},
{
"addr" : "69.9.117.241:58614",
"services" : "00000001",
"lastsend" : 1377526349,
"lastrecv" : 1377526349,
"conntime" : 1377526348,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : true,
"releasetime" : 0,
"startingheight" : 90947,
"banscore" : 0
}
]

[Pmalek]

Mullick whats going on man? Why the forks again?

[ISAWHIM]

Mullick whats going on man? Why the forks again?

Some clients just keep losing connections, plus POS is still being generated, causing forks. The clients/wallets are not correctly navigating back to a chain, once the fork happens. They just stay forked. Which-ever one you find first is the one you remain "stuck" on.

That is being addressed, for the next version.

Until then, the block-crawler is the first sign, along with your own wallet and miners, to determine if you manually have to hop-chains.

Indication of a fork...
- Diff lower than expected
- Reduced connections, less than normal
- Block-crawler height being higher. (If the block-crawler is lower... do not change anything, it will crawl to your taller chain.)
- Miner disconnection complaining about "Not enough work".

Apparently, more people are turning on POS, and screwing it up faster than normal. (Newcomers, or blind-miners, or idiots wanting that 0.0001 gain which costs them 100's in losses from becoming forked, mining orphans. If they ever repair their wallets, they will see they lost a lot more than they THINK they are making.)

[Jriker1]

Is there a longpoll option for Bottlecaps for solo mining?  Only pool I saw on the main page doesn't resolve when you go to the URL.

Thanks.

JR