I agree they are waiting as some folks seem to be mining happily in their own private world of no wallet updates lol. If you have upgraded make sure your staying up with these peers below they are on the right chain.
If your having issues try deleting the peers.dat as well. I'm not having issues using these settings though I know the cryptsy wallet has but mostly due to the wallet.dat needing a repair from all the madness. Hopefully if the really active folks who upgraded do so stay on the right chain and don't add the bad peers then things will be back on track.
Peers connected (using BottleCaps v1.4.1 and having 76,700+ blocks)
-------------------------------------------------------------------
maxconnections=100
addnode=92.5.104.42
addnode=199.180.115.100
addnode=77.172.80.106
addnode=192.241.222.16
addnode=186.91.190.123
addnode=115.76.11.1
addnode=88.195.204.114
addnode=96.11.62.114
addnode=72.190.53.101
addnode=50.137.233.14
addnode=173.78.24.39
addnode=46.177.38.19
addnode=98.253.19.158
addnode=67.167.228.42
addnode=86.157.171.1
addnode=108.168.0.85
addnode=64.136.208.127
addnode=24.177.66.222
addnode=54.212.80.0
addnode=46.4.74.197
addnode=85.172.112.226
addnode=188.252.16.109
addnode=80.198.94.98
addnode=77.51.121.79
Topic: Bottlecaps 2.1 UPDATE REQUIRED - HARDFORK JULY 4 2014 to 200% Annual PoS - page 181. (Read 388610 times)
August 16, 2013, 01:49:52 PM
August 16, 2013, 12:36:46 PM
OK I dont unerstand, will there be another fix or what?
I'd imagine the devs are waiting to see what happens when the old clients get disconnected at 12 noon EST tomorrow.
If there are still forks after that, fixes will be needed. Until then, people will need to be constantly checking to make sure they're on the right chain.
August 16, 2013, 12:24:30 PM
OK I dont understand, will there be another fix or what?
August 16, 2013, 12:00:57 PM
YES!
Second block found was my first POS block! (Only took a month to find one! lol.)
Also note, those who have not updated yet... get the latest cgminer 3.3.4, just in-case that may be the underlying source of some "submission" issues. They did more "block-detection" code to reduce "still working on expired block" parts of the code. (Eg, faster response to killing old work, getting you working back on the new block faster. Might help a little with stales.)
Second block found was my first POS block! (Only took a month to find one! lol.)
Also note, those who have not updated yet... get the latest cgminer 3.3.4, just in-case that may be the underlying source of some "submission" issues. They did more "block-detection" code to reduce "still working on expired block" parts of the code. (Eg, faster response to killing old work, getting you working back on the new block faster. Might help a little with stales.)
August 16, 2013, 12:00:50 PM
I have the strangest feeling that ISP's and GOVT's are beginning to block "bitcoin-like" packet data and ports.
This can't be just a software issue, because this software ran perfectly up until just recently. This is not the only coin having issues. Unless there is some new exploit being used, that has not been detected or addressed yet.
Also note, even TOR and torrents have had similar issues with this recently. ISP's purposely killing TOR and torrent traffic, or anything they "consider to be bandwidth-limiting to other customers".
Which includes trimming data-packets, closing connections, and purposely corrupting data that they find to be "a burden to network traffic".
The problem is... the programs are not compensating for the failures of TCP data, which they easily fake as being successfully delivered. UDP data evades this, as it requires non-standard correction and delivery methods that they can not fake. (Eg, if they alter it, and can't fake a successful delivery, like they can with TCP, they just get flooded with more UDP sends.)
P.S. I eventually got on a tall chain, still with only 1 connection... height 76332... Hope that is the right one. (Stopping at block 60000 and backing-up, so I don't have to keep redownloading over and over and over and over... shit that I shouldn't have to keep redownloading. This thing should be working bckc to the point of the branch, "hard coded block", and rebuilding itself from that point up... every time there is a new height-fork detected.)
I have to keep disconnecting, due to the connection stopping talking to me, not sending the next block... Thus, increasing the chance that the next connection does NOT connect to a tall chain again. Just happened now... caught it in time... new height 76859... this time... with 4 connections.
P.P.S. This is just frustration speaking... I still commend your great work and ongoing efforts, to everyone participating.
This can't be just a software issue, because this software ran perfectly up until just recently. This is not the only coin having issues. Unless there is some new exploit being used, that has not been detected or addressed yet.
Also note, even TOR and torrents have had similar issues with this recently. ISP's purposely killing TOR and torrent traffic, or anything they "consider to be bandwidth-limiting to other customers".
Which includes trimming data-packets, closing connections, and purposely corrupting data that they find to be "a burden to network traffic".
The problem is... the programs are not compensating for the failures of TCP data, which they easily fake as being successfully delivered. UDP data evades this, as it requires non-standard correction and delivery methods that they can not fake. (Eg, if they alter it, and can't fake a successful delivery, like they can with TCP, they just get flooded with more UDP sends.)
P.S. I eventually got on a tall chain, still with only 1 connection... height 76332... Hope that is the right one. (Stopping at block 60000 and backing-up, so I don't have to keep redownloading over and over and over and over... shit that I shouldn't have to keep redownloading. This thing should be working bckc to the point of the branch, "hard coded block", and rebuilding itself from that point up... every time there is a new height-fork detected.)
I have to keep disconnecting, due to the connection stopping talking to me, not sending the next block... Thus, increasing the chance that the next connection does NOT connect to a tall chain again. Just happened now... caught it in time... new height 76859... this time... with 4 connections.
P.P.S. This is just frustration speaking... I still commend your great work and ongoing efforts, to everyone participating.
Well I'm sure that some VPS providers are probably blocking bitcoin-like data with the rash of people buying cheap VPS's and running the CPU to 100% 24x7 to mine things like XPM.
August 16, 2013, 11:23:39 AM
I have the strangest feeling that ISP's and GOVT's are beginning to block "bitcoin-like" packet data and ports.
This can't be just a software issue, because this software ran perfectly up until just recently. This is not the only coin having issues. Unless there is some new exploit being used, that has not been detected or addressed yet.
Also note, even TOR and torrents have had similar issues with this recently. ISP's purposely killing TOR and torrent traffic, or anything they "consider to be bandwidth-limiting to other customers".
Which includes trimming data-packets, closing connections, and purposely corrupting data that they find to be "a burden to network traffic".
The problem is... the programs are not compensating for the failures of TCP data, which they easily fake as being successfully delivered. UDP data evades this, as it requires non-standard correction and delivery methods that they can not fake. (Eg, if they alter it, and can't fake a successful delivery, like they can with TCP, they just get flooded with more UDP sends.)
P.S. I eventually got on a tall chain, still with only 1 connection... height 76332... Hope that is the right one. (Stopping at block 60000 and backing-up, so I don't have to keep redownloading over and over and over and over... shit that I shouldn't have to keep redownloading. This thing should be working bckc to the point of the branch, "hard coded block", and rebuilding itself from that point up... every time there is a new height-fork detected.)
I have to keep disconnecting, due to the connection stopping talking to me, not sending the next block... Thus, increasing the chance that the next connection does NOT connect to a tall chain again. Just happened now... caught it in time... new height 76859... this time... with 4 connections.
P.P.S. This is just frustration speaking... I still commend your great work and ongoing efforts, to everyone participating.
This can't be just a software issue, because this software ran perfectly up until just recently. This is not the only coin having issues. Unless there is some new exploit being used, that has not been detected or addressed yet.
Also note, even TOR and torrents have had similar issues with this recently. ISP's purposely killing TOR and torrent traffic, or anything they "consider to be bandwidth-limiting to other customers".
Which includes trimming data-packets, closing connections, and purposely corrupting data that they find to be "a burden to network traffic".
The problem is... the programs are not compensating for the failures of TCP data, which they easily fake as being successfully delivered. UDP data evades this, as it requires non-standard correction and delivery methods that they can not fake. (Eg, if they alter it, and can't fake a successful delivery, like they can with TCP, they just get flooded with more UDP sends.)
P.S. I eventually got on a tall chain, still with only 1 connection... height 76332... Hope that is the right one. (Stopping at block 60000 and backing-up, so I don't have to keep redownloading over and over and over and over... shit that I shouldn't have to keep redownloading. This thing should be working bckc to the point of the branch, "hard coded block", and rebuilding itself from that point up... every time there is a new height-fork detected.)
I have to keep disconnecting, due to the connection stopping talking to me, not sending the next block... Thus, increasing the chance that the next connection does NOT connect to a tall chain again. Just happened now... caught it in time... new height 76859... this time... with 4 connections.
P.P.S. This is just frustration speaking... I still commend your great work and ongoing efforts, to everyone participating.
August 16, 2013, 11:05:06 AM
Getting stuck with only 1 connection, at height 75522 of 76795 (Says only 2 minutes ago, which is impossible that 1000 blocks were generated in 2 minutes)
So now we have four forks... one for each old version, plus two for this version.
This could be alleviated if you code a "next-version salt-hash", within the previous version. Thus, each new hard-coded block-height has a unique valid salt. If a new salt-hash is detected on a larger height, which each miner should be checking with a free connection, the entire time it is mining, looking for taller chains and new versions... then it stops mining and warns that an update is needed.
EG, you, (the original creator", would have to precompile a dummy "next version", to get that next-version hash for the salt it will use. No-one would know the salt, just the hash of the salt... which they could not fake, without actually knowing the next salt to be used. (Which you would have to be 100% sure never to loose... and make it non-obvious, unlike salt "0", then "1", then "2"... etc... Because losing that salt, which matches the hash, would effectively kill the coin instantly, as the next salt would not match, and you wouldn't be able to guess it yourself.)
But anyways, the disconnect issue is still present. I get 1 of about 30+ connections, 2 at times, but they never send the data, or they are sending the data, but it is coming back NULL or unreadable or untranslatable.
If we all keep deleting the database, which should never be a requirement, that will keep all miners constantly uploading the database, and keep creating more forks too. If they are uploading, they are not downloading in time, and forking. It's a catch 22. Those with the longest forks, are too busy to upload the fork they are building, and refusing to tell us what we need to know, to build on them. (Eg, they are selfishly hoarding their tall chain, to build on it, not letting us build on it, which would interfere with them building it taller. That would be fixed if you DEMANDED that no more than 6 blocks could be built, before it HAD to get another block-solution-height from another account, as the solver, before it could continue to add another block to the height.)
EG, talk to the network, or die on your own unacceptable tall chain of invalids and orphans.
I love this...

[
{
"addr" : "198.211.116.19:7685",
"services" : "00000001",
"lastsend" : 1376669117,
"lastrecv" : 1376669016,
"conntime" : 1376668001,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 75525,
"banscore" : 0
},
{
"addr" : "106.187.100.78:7685",
"services" : "00000001",
"lastsend" : 1376669032,
"lastrecv" : 1376669032,
"conntime" : 1376668574,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 75527,
"banscore" : 0
},
{
"addr" : "81.105.30.173:7685",
"services" : "00000001",
"lastsend" : 1376669100,
"lastrecv" : 1376669117,
"conntime" : 1376669099,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 3000,
"banscore" : 0
}
]
startingheight 3000
add yet another fork...
So now we have four forks... one for each old version, plus two for this version.
This could be alleviated if you code a "next-version salt-hash", within the previous version. Thus, each new hard-coded block-height has a unique valid salt. If a new salt-hash is detected on a larger height, which each miner should be checking with a free connection, the entire time it is mining, looking for taller chains and new versions... then it stops mining and warns that an update is needed.
EG, you, (the original creator", would have to precompile a dummy "next version", to get that next-version hash for the salt it will use. No-one would know the salt, just the hash of the salt... which they could not fake, without actually knowing the next salt to be used. (Which you would have to be 100% sure never to loose... and make it non-obvious, unlike salt "0", then "1", then "2"... etc... Because losing that salt, which matches the hash, would effectively kill the coin instantly, as the next salt would not match, and you wouldn't be able to guess it yourself.)
But anyways, the disconnect issue is still present. I get 1 of about 30+ connections, 2 at times, but they never send the data, or they are sending the data, but it is coming back NULL or unreadable or untranslatable.
If we all keep deleting the database, which should never be a requirement, that will keep all miners constantly uploading the database, and keep creating more forks too. If they are uploading, they are not downloading in time, and forking. It's a catch 22. Those with the longest forks, are too busy to upload the fork they are building, and refusing to tell us what we need to know, to build on them. (Eg, they are selfishly hoarding their tall chain, to build on it, not letting us build on it, which would interfere with them building it taller. That would be fixed if you DEMANDED that no more than 6 blocks could be built, before it HAD to get another block-solution-height from another account, as the solver, before it could continue to add another block to the height.)
EG, talk to the network, or die on your own unacceptable tall chain of invalids and orphans.
I love this...

[
{
"addr" : "198.211.116.19:7685",
"services" : "00000001",
"lastsend" : 1376669117,
"lastrecv" : 1376669016,
"conntime" : 1376668001,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 75525,
"banscore" : 0
},
{
"addr" : "106.187.100.78:7685",
"services" : "00000001",
"lastsend" : 1376669032,
"lastrecv" : 1376669032,
"conntime" : 1376668574,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 75527,
"banscore" : 0
},
{
"addr" : "81.105.30.173:7685",
"services" : "00000001",
"lastsend" : 1376669100,
"lastrecv" : 1376669117,
"conntime" : 1376669099,
"version" : 70000,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 3000,
"banscore" : 0
}
]
startingheight 3000
add yet another fork...
August 16, 2013, 10:24:20 AM
Yes well I do that every as often as I can......for obvious reasons.
August 16, 2013, 10:14:35 AM
Yes I mined 4 blocks on that one and am back on right (?) chain now.
http://bottlecaps.kicks-ass.netIs on the right chain, always check there.
August 16, 2013, 10:07:56 AM
Yes I mined 4 blocks on that one and am back on right (?) chain now.
August 16, 2013, 10:02:30 AM
I have issues again this morning. Left the client up all night and generating POS but it was 120 blocks behind. Shut it down and restarted and it would not connect. Shut down, cleared the folder and restarted again with the peer list from http://bottlecaps.kicks-ass.net/peers.php and still no connections. Strange.
There was a fork again:
One chain is 76,692 and http://bottlecaps.kicks-ass.net/ is on it
Another one is 76,447 and somehow i'm on it and I do have 1.4.1
Dang can't be happening again
August 16, 2013, 09:59:06 AM
from my wallet to cryptsy.com
Status: 47 confirmations, broadcast through 7 node(s)
Date: 2013/8/16 09:15
To: EjDRMgRp95AcvJqJANZeNUvntWhrzGxaC7
Debit: -49.90 CAP
Transaction fee: -0.001 CAP
Net amount: -49.901 CAP
Transaction ID: 9fcd0977f3ab86f86b3ed70488b0b8e28c3188bc399ea7bd00415f90f125bb2e
cant find coins on cryptsy now
Status: 47 confirmations, broadcast through 7 node(s)
Date: 2013/8/16 09:15
To: EjDRMgRp95AcvJqJANZeNUvntWhrzGxaC7
Debit: -49.90 CAP
Transaction fee: -0.001 CAP
Net amount: -49.901 CAP
Transaction ID: 9fcd0977f3ab86f86b3ed70488b0b8e28c3188bc399ea7bd00415f90f125bb2e
cant find coins on cryptsy now
August 16, 2013, 09:11:57 AM
Another fork? I guess that was always going to be a danger whilst there is a mix of updated and non-updated clients out there, just because you're adding nodes from my list it doesn't prevent other peers from connecting to you and leading you down a dead end fork.
You should really use the procedure I outlined earlier to prevent other nodes from connecting to you whilst you download the blocks:
I can always archive my blocks and put up a download link if that will help?
EDIT: Restarting my daemon so I can get some up to date block counts off any peers connecting to me.
EDIT 2: http://bottlecaps.kicks-ass.net/peers.php is now only listing peers that are using BottleCaps v1.4.1 and have 76,700 blocks at the very least (current = 76,722).
You should really use the procedure I outlined earlier to prevent other nodes from connecting to you whilst you download the blocks:
All you need to do to get back on track is:
- Close your bottlecaps wallet
- Navigate to the %Appdata%\bottlecaps folder and delete everything (except wallet.dat and bottlecaps.conf)
- Open bottlecaps.conf in a text editor such as notepad and delete any current addnode= or connect= lines.
- Visit this link and copy and paste the contents (excluding the page title) into the file.
- Use the find and replace feature of the text editor to replace all instances of addnode= with connect= and then save the file.
- Start up bottlecaps and it should start to sync. Once you're synced (you can confirm the block count here) you should close your bottlecaps wallet once again.
- Open bottlecaps.conf (if it's not still open) and use the find and replace feature of your text editor to change all instances of connect= back to addnode= and then save the file.
- Start up bottlecaps and you should now be good to go.
I can always archive my blocks and put up a download link if that will help?
EDIT: Restarting my daemon so I can get some up to date block counts off any peers connecting to me.
EDIT 2: http://bottlecaps.kicks-ass.net/peers.php is now only listing peers that are using BottleCaps v1.4.1 and have 76,700 blocks at the very least (current = 76,722).
August 16, 2013, 09:05:54 AM
I have issues again this morning. Left the client up all night and generating POS but it was 120 blocks behind. Shut it down and restarted and it would not connect. Shut down, cleared the folder and restarted again with the peer list from http://bottlecaps.kicks-ass.net/peers.php and still no connections. Strange.
There was a fork again:
One chain is 76,692 and http://bottlecaps.kicks-ass.net/ is on it
Another one is 76,447 and somehow i'm on it and I do have 1.4.1
August 16, 2013, 08:43:44 AM
I have issues again this morning. Left the client up all night and generating POS but it was 120 blocks behind. Shut it down and restarted and it would not connect. Shut down, cleared the folder and restarted again with the peer list from http://bottlecaps.kicks-ass.net/peers.php and still no connections. Strange.
August 16, 2013, 05:55:22 AM
good job guys 
i updated everything looks fine, except verns pool which reporting 10 blocks ahead of my wallet/explorer.
i cash out 10 5min ago havent got my CAPs yet
i updated everything looks fine, except verns pool which reporting 10 blocks ahead of my wallet/explorer.
i cash out 10 5min ago havent got my CAPs yet
did i lose my CAPs or is there something can be done?
If you are on the right chain they should go through. Was the transaction from your wallet? Also are you still on the correct chain matching here?
http://bottlecaps.kicks-ass.net/peers.php
from the pool to my wallet
edid : redownloading to see what happens..
update
with those i got only 4 connected
addnode=199.180.115.100
addnode=92.5.104.42
addnode=67.167.228.42
addnode=4.30.96.132
addnode=50.137.233.14
addnode=199.180.115.100
addnode=108.168.0.85
addnode=192.241.216.151
addnode=46.177.38.19
addnode=80.229.2.127
addnode=220.200.7.176
addnode=71.187.248.95
just received my CAPs from Vern's pool (still down), There are some hiccups downloading the blockchain, and it seems that i'm stuck at block 75488
re-downloaded again with only addnode=199.180.115.100 in conf, my CAPs from vern's pool never confirmed
F@@K.. and lost connections at 76575 block..at last!!, re-opened my client..
dowloaded the whole chain : check
on the right chain (according to explorer) : check
my CAPs confirmed : check
i'm tired but happy
August 16, 2013, 04:49:41 AM
Well a little of both. Petrified did some work with gamecoin and its forking issues that I applied to caps. Sunny king helped point out the PoS issue. I went through did the code compiled client got them to sync with the required checkpoints ect. I will continue to strengthen the network with further updates. Currently working on the novacoin-seeder here https://github.com/CryptoManiac/novacoin-seeder
So I had a lot of help but there was a lot of testing to be done hence the delays
1.5 is done but we need to get the network on the same page before we introduce any more drastic changes so its expected shortly. Ill update the changes to the development branch and comment them out for now. Sometime soon
Hmm interesting. Good work, I like the way that it is oging to solve those issues. Maybe hold the update till begining of september of end of august? So I had a lot of help but there was a lot of testing to be done hence the delays
1.5 is done but we need to get the network on the same page before we introduce any more drastic changes so its expected shortly. Ill update the changes to the development branch and comment them out for now. Sometime soon
August 16, 2013, 04:45:14 AM
As a precaution remove 50.137.233.14 from your .conf file. It is having connectivity issues
August 16, 2013, 12:19:57 AM
good job guys
i updated everything looks fine, except verns pool which reporting 10 blocks ahead of my wallet/explorer.
i cash out 10 5min ago havent got my CAPs yet
i updated everything looks fine, except verns pool which reporting 10 blocks ahead of my wallet/explorer.
i cash out 10 5min ago havent got my CAPs yet
did i lose my CAPs or is there something can be done?
If you are on the right chain they should go through. Was the transaction from your wallet? Also are you still on the correct chain matching here?
http://bottlecaps.kicks-ass.net/peers.php
August 16, 2013, 12:16:15 AM
Looks like this has been a great community effort mullick great work hope it all goes well .
Jump to: