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

[Thrash]

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.

[kslavik]

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

[Petr1fied]

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:

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

[lemons]

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  

[Lauda]

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

Updated correctly?
Dang can't be happening again 

[butjust41day]

Yes I mined 4 blocks on that one and am back on right (?) chain now.

[Lauda]

Yes I mined 4 blocks on that one and am back on right (?) chain now.

http://bottlecaps.kicks-ass.net
Is on the right chain, always check there.

[butjust41day]

Yes well I do that every as often as I can......for obvious reasons.

[ISAWHIM]

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

[ISAWHIM]

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.

[flound1129]

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.

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.

[ISAWHIM]

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

[Pmalek]

OK I dont understand, will there be another fix or what?

[flound1129]

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.

[BitJohn]

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

[ISAWHIM]

That is the list that I use, as it has the highest block-height. (Works for me now, after constant restarting, to get that right height.)

Odd things happening...

My staked coins just went from 70.07 to 60.05 when I got another POS...

Also note... I went from having no POS for a month (with POS ready blocks), to having 7 in a few hours... The odd thing is, the POS rewards are 0 then 0.01 than 0 then 0.01, and they are going into POS only. I thought the 0.01 reward was going to show as a normal TX? EG, 70 staked results in 0.07 reward that shows in actual coins, not back as more POS staked coins... Which would leave tons of staked coins that can never be touched?

Or will those later roll-out of stake, into a normal coin, after the 90 days? (Eg, they unstake themselves.)

As I wrote this, I am now up to 80.07 staked... lol, it gave me one of the 10-coins, but rejected one of the reward POS blocks of 0.01... odd again. I guess the reward was inside of the "next block", but the "next block" it was in, was rejected by the network... so I lose my reward which was in that block as a transaction to the coins that were moved in the prior block... that's annoying.

Also note, annoying CGMINER change...
Accepted no longer shows the number accepted, it shows the DIFF of the last accepted block. SO much for tracking how many accepts/rejects we get now...

EG, it shows A: 70687 lol... Yay, 70,000 accepted blocks and only 0 rejects! great odds! lol (Sent a notice to the devs of CGMINER.)

I have 11 (confirmed) 0.01 blocks, and only 6 apparently show as staked?
I have 1 (confirmed) 0.00 blocks, and 70 show as staked?
Total: 70.06, should be 10.11? or 60.11??? (2 10's resulting in 1 of 0.01)

POS blocks total (not including the ones still pending confirms)
12 total confirmed, indicating 80.07 staked
8 total unconfirmed

2 are 0.00 blocks
18 are 0.01 blocks

[Petr1fied]

I can always archive my blocks and put up a download link if that will help?

Further to this, when I restarted my daemon earlier I backed up my blocks in the %Appdata%\bottlecaps folder. At the time it was up to block 76,709 (We're currently on 77,009 as I type this).

Here is the download link

You may need to start your client with the -rescan flag if you use this.

[Thrash]

I can always archive my blocks and put up a download link if that will help?

Further to this, when I restarted my daemon earlier I backed up my blocks in the %Appdata%\bottlecaps folder. At the time it was up to block 76,709 (We're currently on 77,009 as I type this).

Here is the download link

You may need to start your client with the -rescan flag if you use this.

Thank you! That got me back on the correct chain. Cost me another 500 coins though. 
Total of over 1000 lost due to wrong chain issues. Oh well, life goes on.

Guess I better get to mining to get some back. Hopefully it stays were it belongs this time.

[feeleep]

I think I finally managed to update http://cap.coinmine.pl to latest client and successfully download blockchain. Please send some hashes here to test current setup.

[chondrite]

I've redownloaded the blockchain several times now (first downloaded an hour after it was posted) with various addnodes listed from today.  My client is still hanging back about 7000 blocks.  Nothing is changing, I get stuck on a bad chain everytime.