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

Here is the link to the block chain with 72636 blocks:

http://www.karasoft.com/BottleCaps72636.rar

Edit: Did you delete your block chain first? and overridden it with the block chain from the archive?
Edit2: you must close your bottlecaps client before you delete and override the block change database

That still says the same thing... block-height 72044 and it is constantly rejecting my connections...

The point of having a "reliable connection", is that it is reliable...

If we have to constantly keep manually connecting (apparently to the wrong chain that some individual wants us to connect to, instead of the one that works naturally), then there is no point mining on that poor connection, which will just continue to lead to crap like this.

The list of connections provided connects fine, well 4 connections... Removing all connections connects fine, to the same 4 connections. Not sure what is going on here, but it seems as though someone is purposely screwing with the networks in the pools. That, or they all have corrupted data, or they are isolating themselves, which is effectively doing a 51% attack, and then asking us to join the attacking chain, but refusing our connections.

You guys might want to check your ISP's, and see if they are rejecting our connections, which is keeping YOU isolated from US.

connection to IP 92.5.104.42 is not accepting connections, constantly closing them once connected.

Going back to the one that connects, which will rise above the others. I suggest you do the same. The other chains are high diff, and not growing as fast, and are selective to whom they talk with. You will constantly be forking talking to those unreliable connections.

Add the following to your bottlecaps.conf:

connect=92.5.104.42

and take out all your addnodes

You can download blockchain from several days ago from here http://www.karasoft.com/BottleCapsLast.rar

Once you done with the update modify back your bottlecaps.conf

I honestly think the other guys need to redownload... Our clients are rejecting the other chains for a reason... Are they failing an audit?

Block-height of the ONLY chain I can connect to, with all settings mentioned above, is still 72042.

I am guessing someone is using a client that is rejecting "speaking" to us, by killing our connections, if there isn't something "failing" in the other block-heights. Because they seem to be isolating themselves, and this chain will eventually topple-over the others, with the diff so low. (My wallet sees other heights, but no-one is delivering them... or they are, and they are failing an audit, thus, not accepted by the wallet as a "valid chain block".)

Sorry, but unless the others connect, I am going to just mine the hell out of the low diff chain until it surpasses the others. It is the only one passing an audit in my wallet, apparently.

I'm using the 1.40 update with the nodes posted in the OP.  My client is on a different block than bottlecapspool and the block explorers.  I've redownloaded the blockchain, tried without the nodes, still get the same chain that is different from other services.  Any idea on how to get my client back on the right chain?

I think the problem is that forks are not detected by the client and even if they are, there is no code to pick the best branch.
The client should always detect the longest chain and switch into it. It should be part of the code, right?

I also think that POS blocks should have lower priority than POW blocks, because POS are there to support the network when there are no POW blocks found.

Very cool I already put in my order for some jerky!

I think it just needs to use a more precise time, 1 second can be a long time when you have 2 different type of blocks that can be generated (one of which very easily).

Why not just make the time of block generation more precise by using milliseconds or even microseconds? The chances of a clash would then be much less likely and the winning block would invariably be the one with the smallest number of [milli/micro]seconds over the full second.

The chances of a clash when using milliseconds is 1 in 1,000
The chances of a clash when using microseconds is 1 in 1,000,000

Minor setback on the 1.41 wallet update still intend to have it out there soon. The forks folks are seeing all appear to be from people connecting to peers on old wallets running old chains. Haven't seen the issues running the wallet on the correct peers with the upgraded wallet.

In the meantime:

With CAP's you can now buy:
Buy sauce with coins http://sauce4coins.com/
Buy Steam games http://coingas.com
Buy Jerky and Goodies http://jaysjerkyandgoodies.com/

Support these vendors with your CAP's

There are three chains...

One with diff 16K (0.244) @ block height 72031...
Plus one at height 72538...
Plus one at height 72129...

Something should be set, in code, to accept POS over POW, in the event where both are found at the same time. (If branched, the branch without the POS should immediately die, as it should be seen as invalid. Same when looking for block-heights. Since POS take almost no time to create, once the system decides it is time to create one. Killing the non-POS branch, which would interfere with the security that POS is intended to add. EG, building a chain on the non-POS branch would eventually lead to a separate POS there, causing another split... However, if the only chains accepted are the ones with the earliest POS, then we are all building off the same chain. Reducing the splitting, unless there truly is a network separation.)

Also note... this would require a constant "roaming" free IP slot. (Or multiple ones), so the wallets/coind can constantly "explore" for networks. Once they find x-connections, they stay there, as long as those connections are not lost. That should not be. Connections should be randomly closed, and replaced by ones that have not been tried yet. (Or ones that have not been tried in a while.)

I suggest closing one connection per x-blocks found, unless a replacement connection has not been found after having closed on a block previously found.

Well it's getting fixed which should give you more faith in the coin. The developers are active, no pre-mined occurred and a POW/POS coin. These things make me really like this coin. Besides CAPs are fun.
 

I certainly have!  Doesn't look very promising when this is a recurring theme...

The longer chain typically wins when there is a fork because more people will lose their coins if they go with the shorter chain. It's in your best interests to get onto the longer chain as soon as possible. If you need a list of nodes then visit my block crawler which is on the longer chain and click the link under Connections:



It'll give you a nice preformatted list of addnode lines to get you back on track.


I've PM'd you a download link for my debug.log.

Which one is a correct chain now?

72129 blocks with 1.43 diff or

71967 blocks with 0.25 diff (I tried to re-download the chain several times and I always picked this one up somehow)

If you have your debug log please PM me with a download link

New info:

Both versions of block 71897 were found at exactly 3:58:06

Half the network accepted the PoS block and half accepted the PoW block

All my nodes are on that chain as well. It appeared as thought the network was intact because all my nodes, both block explorers and the only pool in operation are all on the same chain.

This appears to be a whole other beast. All theorys about it being network communication are out the window. 23 connections on one chain 29 on the other

Occurred at block 71897 a PoS block. It appears half the network accepted it and the other half didnt.



ProcessBlock: ACCEPTED
received block 0000000077346f539791
SetBestChain: new best=0000000077346f539791  height=71894  trust=3171643634  date=08/13/13 03:56:24
ProcessBlock: ACCEPTED
received block 000000001b51fe0cc2b9
SetBestChain: new best=000000001b51fe0cc2b9  height=71895  trust=3171643635  date=08/13/13 03:56:29
ProcessBlock: ACCEPTED
received block 0000000057f1338b9272
SetBestChain: new best=0000000057f1338b9272  height=71896  trust=3171643636  date=08/13/13 03:57:14
ProcessBlock: ACCEPTED
received block 2c5744b9101da431f221
SetBestChain: new best=2c5744b9101da431f221  height=71897  trust=3188421108  date=08/13/13 03:58:06


I understand people will lose faith because this happened again.  I assure you I am working tirelessly to get to the bottom of it. I am a volunteer who picked this project up.  I have never been paid 1 cent for any work. I am doing this to fix what I believe to be a great coin. Fair launch, great community ect.

The issues appear to have been present before I took over. As checkpoints were all that was added in the release 11 days prior to the first incident.

Whatever the cause it appears drastic changes will need to be made. It may be a flaw in the stake system.

As a temporary measure to prevent these issues everyone please set:

reservebalance=1000000

In your .conf file. This will prevent PoS blocks from being generated until the issue can be resolved. Unless you have more than 1 million coins

I will need a debug log from anyone on the longer chain. Which appears to be mainly verns pool which is finding the blocks as once again 90%+ of the hashpower is contained there since currently it is one of 2 pools in operation.

More updates to come soon. Whichever chain contains the most miners/ coins will be chosen as usual


No changes to stake whatsoever have been made.

Ah this is what I half expected , although my post on this topic was maybe taken the wrong way at the time,  this is what I was trying to discover , interesting is it not , the trade off of adjustment to other effects .

Nope I have 23 connections. The stuff under pool stats is wrong, I'm at block 71921.

$ bottlecapsd getpeerinfo|grep addr|wc -l
23
$ bottlecapsd getpeerinfo|grep addr
        "addr" : "199.180.115.100:64480",
        "addr" : "70.98.114.237:43909",
        "addr" : "70.27.70.224:54674",
        "addr" : "50.137.233.14:53243",
        "addr" : "68.115.163.162:54551",
        "addr" : "76.110.255.33:62841",
        "addr" : "24.71.137.254:60082",
        "addr" : "72.202.148.137:49660",
        "addr" : "64.251.188.62:57625",
        "addr" : "50.2.8.67:34206",
        "addr" : "184.166.242.244:52371",
        "addr" : "50.149.211.203:52865",
        "addr" : "76.11.149.208:55060",
        "addr" : "91.109.5.247:55664",
        "addr" : "70.79.24.157:50460",
        "addr" : "71.46.67.79:62541",
        "addr" : "86.162.196.60:46728",
        "addr" : "107.217.208.215:58003",
        "addr" : "24.177.66.222:53068",
        "addr" : "68.81.64.95:53009",
        "addr" : "4.30.96.132:57798",
        "addr" : "89.168.3.49:56523",
        "addr" : "115.76.11.1:57774",

Nope network intact. The webooise explorer stops updating every once in a while and thats the api coinchoose uses.

I see your block count is almost 30k behind. You must have found the bad chain again when you restarted. Im guessing you have very few or just 1 connection?

Redownload chain and restart with

listen=1
addnode=199.180.115.100
addnode=50.137.233.14
addnode=54.232.197.215
addnode=54.221.200.186

I have been doing lots of testing on the new client. Sorry for thee delay but im not about to release untested code. Hoping to have it done tomorrow. Network appears to be stable

The problem is with the difficulty algo. When a fork happens on a coin with a standard retarget every x amount of blocks the forked chain dies fast. As the hashrate moves away and no more blocks are found by the few remaining.

But with caps difficulty algorithm a few hundred KH is all thats required to keep the chain moving. and the slower people move to the correct chain the faster it drops as they are still finding block which drop the difficulty 10%+ each

Good for sites like coinchoose as they dont leave the chain stranded when they leave. But bad in a situation like this. That one forked chain just wont die.

That is why drastic changes are needed in 1.4.1 and I wont release until I am posotive it will do what I want