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

No

If you were mining and not creating POS, then your wallet is not broken, and you are not the source of the "worsening" issue. Broken = does not work. If you came here to post that reply, you are trolling. So keep your personal biased  judgement about my factually unbiased judgement to yourself. Hypocrite.

It is ignorance (ignoring the issue and solution, for personal gain, at the cost of the others.)
It is stupidity (the opposite of smart, selfishly leaving it on, for personal gain, at the cost of the others.)
->
Related to "worsening" the issue. (Making it "worse", when it would otherwise not be "as bad".)


LOL, they forgot "broken back mountain" and "brokers" and "crashed" and... (Sarcasm for the stupidly published and poor definition crap they teach in schools. Webster was a moron. #10 would have sufficed, but they obviously like to fill white space to sell themselves as being smart, just making themselves look dumb in the process. I am guilty of that myself. I am a hypocrite too. We all are.)

The program functions, just not the way it was expected, on all machines. It does exactly what other coins do... it forks. It just doesn't recover WELL on ALL MACHINES. Some machines it does. No other form of the word "broken" applies to this coin, without also applying to all other coins that exist.

The chain is broken... that is called a fork. Every coin forks, a lot. Most forking happens fast and dies fast and fixes itself. These forks just have "issues" being fixed. Which is "worsened" by those still throwing POS blocks at the chains.

Thanks for keeping this up. Seems the safest is to use your chain as the de-facto reference. Without your effort we would be left in the dark until 1.5.

My mining wallet is now back in-synch with 16 connections (and growing), and back on your connection list.

Keep your judgment to yourself.

I had no stake mining in my broken wallet. The wallet was used only for solo mining @9MH/s. My wallets with stakes are offline.

And that car you talking about isn't broken, works fine... and the drivers/users are idiots anyway for choosing this brand of car

The coin is not broken... It is running fine. The wallets are "acting-up", making it "difficult", but it is not "impossible to mine", thus, not "broken".

The last 30 posts have given instructions to disable POS. The last versions have severed the older versions, thus, they have all seen the request to stop POS, and instructions how to do that... (Though, I agree POS should be disabled in the client, by the software, by default, until that part is resolved.)

At this point, it is ignorance or stupidity "worsening" the issue. The fault of the program formula has already been addressed, and solution is manual, at this point. Any fault now IS on the ones operating the wallets. (Related to that issue.)

Sorry, but if you were told your car has a recall for failing brakes at 65MPH, and you refuse to drive under 65MPH until you can have it repaired for free... It is your own fault if you die in a crash because your brakes failed at 70MPH. By default, brakes work, but you don't have to drive the car. That is your choice, thus, your fault. (Not directing that to you... unless you are driving!)

Ofc it's the users fault coin is broken, PoS mining is on by default you know...

You would think that is how it operates... but it does not. You have to have a lot of connections... that are also "getting blocks from" that tall chain.

We all see it... we all know it is 43 blocks behind... but our wallets never sync with that chain, because we, and the connections we have, have been severed... and/or we can not "repair" the incorrect blocks, correcting them with the correct blocks from the taller chain.

Lack of connections just makes that happen faster. (The clients have issues with connections.)

Your block-crawler has been able to stay 90% on track, and you fix it fast... so thus... it is mostly on the tallest chain. That is our only resource for block-height, except our wallets or the forums. (The forums just are not fast enough to check block-height. By the time you read a post, there could be 20+ more blocks, or 200+ more. As opposed to hitting refresh on your website, or seeing "out of sync" and "45 blocks remaining" in our wallets, which never catches-up, no matter how many connections we have, or how many times we reconnect.)

I still can't get more than 13-14 connections, using the "connect" hack/trick. (But, most wallets are like that, for me. I should find-out which ones are not like that, and that might give some insight to the issue that they can't seem to locate. Obviously the coin they are using for cloning has not resolved that issue either. Seems specific to home-users of various windows versions.)

However, it should take only 2 connections to stay up to date, with one roaming one, looking for taller chains. It shouldn't take 10+ connections if we are all doing the same thing, and have the same info.

The issue is this... in time... all connections end-up doing this...

(Group A: height 80000) A,B,C,D,E,F,G,H,I {9 connections} -> Was 18 conn (Half accepted N block, half didn't, taking D block instead.)
(Group B: height 80002) J,K,L,M,N,O,P,Q,R {9 connections} -> (Built off N block, rejecting D block, severed so can't send height to the other half now.)

Then S comes online... S sees us and them... so S joins the N chain (Group B), and tells the D chain (Group A) of the new height. It attempts to send the blocks, which the wallets just can't use to fix the chain, so they keep mining on the chain that they can mine on, the short one. (Never fixing the incorrect height by removing the incorrect orphaned blocks, rebuilding to the taller height.)

Then, that chain eventually fades, as new people and those noticing the issue, fix it manually and join the (Group B), which is now 20 blocks over (Group A). However, some of those connections are getting rejected, because they "are misbehaving", and that keeps the fork alive, instead of them stopping mining on the short fork, the program continues on a fork it knows is not correct. Until they are left alone and no work arrives for them.

Those previously mining the wrong chain, who still have rejection, and who still have those peers to join... keep getting back on the wrong chain. Because they just don't get the other block heights, until S comes online, and S is not rejecting them, because it just got online, and has not rejected them yet. Acting as a thin link... thus, leaving you with 10 connections, but only 1 link to the other chain, through S... if S gets severed, you lose it again... Even with the 10 connections.

My block crawler could potentially end up on the wrong chain, just the same as any of your clients could. It usually comes down to how many peer connections you have. The more you have, the less likely you are to end up on the losing chain because you have more peers telling you which one they believe is the correct chain. The majority will invariably win. The problem is, if you only have 8 connections there is very little margin for error, 4 peers could very easily go one way and the other 4 the other which makes it a coin flip situation for your client when deciding which way to go.

Anyway it's been nearly a week since I restarted my bottlecaps daemon used on the crawler so I've just given it a restart to refresh the peer starting heights. It's now listing peers with at least 91,138 blocks which was my block count at the time of the restart.

Is 1.5 coming or should be downloadable now?  Also guess we shouldn't be mining bottlecaps right now?

Thanks.

JR

+1

Just trying to figure out what happened with my coins on the exchange

v1.5 hopefully will fix that self-forking problem. Then it can back on market.

anyone have a little info on whats going on with this coin? will it be added back to the exchange soon ?

I've usually piggybacked off of pool longpoll support servers as my failover entry in cgminer.conf to identify new blocks faster so is the only time I used LP but perhaps I'm confused as normally pool mine.

JR

There is no LP on ANY solo mining.
LP means that pool require to get new work = new block in network.

Try my p2pool: http://rav3n.dtdns.net:8645

Edit: looks like I`m in the fork too :/

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

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

Mullick whats going on man? Why the forks again?

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
}
]

pool is back on track