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

I second this statement. Whoever runs this mine please fix.

Mullick whats the plan?

The block crawler was reset to only show connections having at least 82,392 blocks. I believe that is why the connection went down to 5, they are now back up to 18 and climbing. I am showing the same and have 25 connections, down from around 30 last night.

Glad your losses are back to a more normal level.

EDIT: Also... Update on 3.3.1 CGminer... I am completely back to my expected 10% losses, actually down to about 5% losses from rejections at the moment. Must be in a good-luck streak. (Only applies to solo miners who submit only blocks, not pool miners who submit shares and blocks.)

Block-crawler is loosing connections fast, down to 5, but it is still on the correct chain, I believe.

I have that same chain with 8 solid connections. Still can't get more than 8 though. Height 82440 @ 9:57 AM (GMT -5)

Still seems as if POS isn't the issue. (Seems like it is one of the indicators of the issue.)

Are you sure there isn't a value like X>=Y but it should just be X>Y due to something like this...
Diff/65536, but the results are off by 1, due to bytes starting at 0 not 1 resulting in 0-65535, where something like the diff had a value added to it... like 1 to make it not-0 for a division formula that would normally failed with an error of division-by-zero.

Eg, we are submitting an honestly valid submission, that the program sees as invalid. (Eg, not meeting the required criteria of being equal-to-or-greater-than. Because every time it is actually equal, it appears to be invalid, because the result is being compared by the modified value which was not remodified to conform to the premodified value.

(Not saying it is that specifically. But as rare as it is to get an exact diff... That would make it appear to be sporadic and without any apparent rhyme or reason. Leading to what the program believes is an honest "misbehaving" client, leading to the mass genocide of connections.)

This would/may be hidden in things like TIME, nonce, hash-diffs... of the most obvious locations, but in an obscure formula... one that might simply shift-bits or may have a signed value passing into an unsigned value, or mismatched value that isn't acting as expected... That, or an issue with 32/64 bit formula variations failing, between OS's. Where the 64-bit formula works as expected, but it provides a different output on the 32-bit version of the formula, operating on a 64-bit system.

Again, I am just throwing things out there... Things that have often caught me in programming, that are not always obvious to see, unless you compare the data at every step. (Compare it as the program sees it, not as an "output", which is converted before displaying.)

Unless everyone turned on POS, on the block-crawler... and the non-POS miners all left "of free will"... Then it is safe to say that POS is not the ONLY thing causing the issue with connections. Though it did aid it to happen faster. POW blocks are higher diff, and rarely hit EQUAL expected values for submission. Less when the blocks are constantly being reset by POS submissions, and even less with multiple high diffs. (Though many POS blocks ARE the exact equal expected diff, because the diff is so low, and there are many more diffs of those lower values. Same will happen at the other end of the spectrum, when diffs are real high, but being further apart, the rejections will be fewer and more catastrophic to those mining, as they will lose more, because those rejected blocks will be high value.)

Multipool CAP pool has been reopened, however I am requiring 200 confirmations before payout.  The Multiport will not mine CAP until all issues have been addressed.

I checked on this and it looks like I made a change to my .conf file a couple days ago. This may have been the cause of my solo-mining issues. I changed it back and everything looks to be fine now.

I still think there is some unresolved issue with the software which prevents it from resolving forks properly. I've watched pool after pool be off only a few blocks and not be able to resolve to the correct chain. This includes silverwolf, epools, bottlecapspool, and now coinmine.

this is insane... Pool indeed was of the chain again and I am considering closing it as I am not able to control account balances in a proper way. I am trying to catch all wrong blocks in a DB so your coins may show up and down values for some time but pool wallet right now has less coins than accounted to users so donations are welcome to cover loses.

feeleep

Whoever runs the cap.coinmine.pl pool, your pool crashed just after mdnight CST, and I was at over 50 coins confirmed balance, and now I am back to just over 20 confirmed.

Ok, so CGminer version 3.3.1 seems to be the last one that functions correctly for scrypt. Apparently the programmer has no interest in scrypt coins, or offering any resolution for them. BTC ASIC lover... You will literally get a cold shoulder if you mention scrypt in that thread. Like solid ice-cold, cold.

Since the diff has gone up, above 0.70, and with the older 3.3.1 CGminer, I am back UP to getting 2-4 blocks per hour off of 3.2MHs. Which was down by 75% when diff was below 0.65, I was only getting about 1 an hour, if that...

I will chalk-it up to a combo of the two... low diff collisions and crappy CGminer version, submitting crap too late.

These versions of CGminer all seem to have the same issues (for scrypt), or worse...
3.3.2 (displays wrong info in accepted and rejected columns, trouble submitting solutions.)
3.3.3 (displays wrong info in accepted and rejected columns, trouble submitting solutions, trouble getting work.)
3.3.4 (displays wrong info in accepted and rejected columns, trouble submitting solutions, trouble with fan control.)

Also note... I had lower and lower hash-rates with each version step-up. (I switched to 3.3.1 originally from 3.1.0, because it gave me better hash-rates and control for my 7970's. Anything above 3.3.1 seems to only focus on ASIC things and FPGA things, degrading scrypt-mining in the process.)

I am almost up to 20,000 coins now... Thanks to the work that has been done so far. Thank-you again, and again, and again! (10,000 were purchased, not mined.)

Solved. You're right. I wasn't able to duplicate the issue while not mining. It looks like a mining only issue, which shouldn't affect the average user.

Thanks for supporting the coin. Here's what I experienced yesterday FYI in case it helps in any way.

My client (Windows v1.4.2) was synced to correct chain on previous shutdown and was started so I could verify a transaction from a pool. The transaction came through and was confirmed, but the client stalled at block 80159, which was about 30 blocks behind what it should have been. I had 5-7 connections at the time. Rather than the usual restart, I left it alone. What I noticed after some time went by, was that the client changed its status from un-synced to synced (green check) at the same stalled block - 80159. It was connected to 5 peers. I checked it later and it was still synced at 80159 with the last block found 35 minutes ago, active connections - 5. I figured it was done, so was surprised when I checked it yet again later and found that it had actually synced to the then current block, but lost all connections but one. The good thing is that is synced up on its own, but the bad is that it took over 35 minutes while being connected to several nodes in order to do that, and then could only maintain 1-2 connections. If I would have been mining or running a pool, this would have definitely created a fork. Here's a partial log of the event. If you need the rest, PM me.



received block 00000000b242da47eee6
SetBestChain: new best=00000000b242da47eee6  height=80155  trust=12085581059  date=8/19/2013 00:16:39
ProcessBlock: ACCEPTED
received block 000000002a35657cd407
connection timeout
SetBestChain: new best=000000002a35657cd407  height=80156  trust=12085581060  date=8/19/2013 00:17:13
ProcessBlock: ACCEPTED
received block 2e419bc2628be60c42a2
SetBestChain: new best=2e419bc2628be60c42a2  height=80157  trust=12102358532  date=8/19/2013 00:18:06
SetBestChain: new best=00000000f01ec685138b  height=80158  trust=12102358533  date=8/19/2013 00:18:08
SetBestChain: new best=00000000756bda21f21c  height=80159  trust=12102358534  date=8/19/2013 00:19:13
ProcessBlock: ACCEPTED
received block 000000002d7eaf5a4381
ProcessBlock: ORPHAN BLOCK, prev=660707e47f144a5b2f95
received block 00000000fd809c8aa415
ProcessBlock: ORPHAN BLOCK, prev=000000002d7eaf5a4381
received block 8264932c0e66bf98f21c
connection timeout
Misbehaving: 92.5.104.42:7685 (0 -> 100) DISCONNECTING
disconnecting node 92.5.104.42:7685
ERROR: ProcessBlock() : block with too little proof-of-stake
getblocks 80005 to 00000000000000000000 limit 500
Added time data, samples 5, offset -7 (+0 minutes)
nTimeOffset = +5  (+0 minutes)
receive version message: version 70000, blocks=80165, us=108.16.165.144:1042, them=80.229.2.127:7685, peer=80.229.2.127:7685
Added time data, samples 6, offset -6 (+0 minutes)
receive version message: version 70000, blocks=80165, us=108.16.165.144:1043, them=85.228.195.71:7685, peer=85.228.195.71:7685
Added time data, samples 7, offset -4 (+0 minutes)
nTimeOffset = +0  (+0 minutes)
receive version message: version 70000, blocks=80165, us=108.16.165.144:1044, them=37.229.117.57:7685, peer=37.229.117.57:7685
Added time data, samples 8, offset +1 (+0 minutes)
receive version message: version 70000, blocks=80165, us=108.16.165.144:1047, them=67.167.228.42:7685, peer=67.167.228.42:7685
getblocks -1 to 00000000000000000000 limit 500
trying connection 68.225.72.67:7685 lastseen=0.9hrs
getblocks -1 to 00000000000000000000 limit 500
trying connection 4.30.96.132:7685 lastseen=354686.7hrs
getblocks -1 to 00000000000000000000 limit 500
getblocks -1 to 00000000000000000000 limit 500
Added 31 addresses from 67.167.228.42: 10 tried, 1502 new
getblocks -1 to 00000000000000000000 limit 500
Added 22 addresses from 85.228.195.71: 10 tried, 1524 new
Flushing wallet.dat
Flushed wallet.dat 10ms
Added 19 addresses from 37.229.117.57: 10 tried, 1543 new
connection timeout
connection timeout
trying connection 37.140.235.84:7685 lastseen=0.9hrs
connected 37.140.235.84:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=37.140.235.84:7685, peer=37.140.235.84:7685
trying connection 217.169.211.146:7685 lastseen=354686.7hrs
partner 37.140.235.84:7685 using obsolete version 60006; disconnecting
ProcessMessage(version, 100 bytes) FAILED
disconnecting node 37.140.235.84:7685
trying connection 95.18.155.214:7685 lastseen=0.9hrs
Added 13 addresses from 80.229.2.127: 10 tried, 1556 new
connection timeout
connection timeout
trying connection 188.165.211.202:7685 lastseen=354686.7hrs
connected 188.165.211.202:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=188.165.211.202:7685, peer=188.165.211.202:7685
trying connection 72.67.145.232:7685 lastseen=0.9hrs
Added time data, samples 9, offset +6 (+0 minutes)
nTimeOffset = +1  (+0 minutes)
Moving 188.165.211.202:7685 to tried
receive version message: version 70000, blocks=80165, us=108.16.165.144:1055, them=188.165.211.202:7685, peer=188.165.211.202:7685
trying connection 188.165.194.201:7685 lastseen=354686.7hrs
Added 8 addresses from 188.165.211.202: 11 tried, 1563 new
Added 3 addresses from 188.165.211.202: 11 tried, 1566 new
connection timeout
connection timeout
trying connection 71.86.172.110:7685 lastseen=11.2hrs
trying connection 115.76.20.64:7685 lastseen=354686.7hrs
connection timeout
IRC got join
connection timeout
trying connection 70.98.114.237:7685 lastseen=0.9hrs
connected 70.98.114.237:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=70.98.114.237:7685, peer=70.98.114.237:7685
socket closed
disconnecting node 70.98.114.237:7685
trying connection 97.81.165.175:7685 lastseen=354686.7hrs
trying connection 50.149.211.203:7685 lastseen=0.9hrs
connection timeout
connection timeout
trying connection 68.43.193.187:7685 lastseen=354686.7hrs
trying connection 117.0.178.244:7685 lastseen=0.9hrs
connection timeout
connection timeout
trying connection 24.52.207.220:7685 lastseen=354686.7hrs
trying connection 24.52.207.220:7685 lastseen=0.9hrs
connection timeout
connection timeout
trying connection 67.11.24.42:7685 lastseen=354686.7hrs
trying connection 192.95.37.194:7685 lastseen=0.9hrs
connected 192.95.37.194:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=192.95.37.194:7685, peer=192.95.37.194:7685
Added time data, samples 10, offset +5 (+0 minutes)
Moving 192.95.37.194:7685 to tried
receive version message: version 70000, blocks=80165, us=108.16.165.144:1068, them=192.95.37.194:7685, peer=192.95.37.194:7685
Added 10 addresses from 192.95.37.194: 12 tried, 1575 new
connection timeout
trying connection 221.2.149.227:7685 lastseen=354686.7hrs
connection timeout
trying connection 106.186.115.181:7685 lastseen=354686.7hrs
connected 106.186.115.181:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=106.186.115.181:7685, peer=106.186.115.181:7685
Added time data, samples 11, offset +5 (+0 minutes)
nTimeOffset = +5  (+0 minutes)
receive version message: version 70000, blocks=80080, us=108.16.165.144:1071, them=106.186.115.181:7685, peer=106.186.115.181:7685
Added 5 addresses from 106.186.115.181: 12 tried, 1580 new
Flushed 1592 addresses to peers.dat  0ms
received block 0000000075fe7ae1a6a4
ProcessBlock: ORPHAN BLOCK, prev=000000006f50e9b86c46
received block 000000006f50e9b86c46
ProcessBlock: ORPHAN BLOCK, prev=0000000081ebea35aed2
received block 0000000081ebea35aed2
ProcessBlock: ORPHAN BLOCK, prev=8264932c0e66bf98f21c
received block 8264932c0e66bf98f21c
Misbehaving: 67.167.228.42:7685 (0 -> 100) DISCONNECTING
disconnecting node 67.167.228.42:7685
ERROR: ProcessBlock() : block with too little proof-of-stake
trying connection 76.27.247.150:7685 lastseen=0.9hrs
connection timeout
trying connection 223.64.63.17:7685 lastseen=354686.7hrs
connection timeout
trying connection 174.107.165.198:7685 lastseen=0.9hrs
connection timeout
trying connection 50.137.233.14:7685 lastseen=354686.7hrs
connected 50.137.233.14:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=50.137.233.14:7685, peer=50.137.233.14:7685
Added time data, samples 12, offset +14 (+0 minutes)
receive version message: version 70000, blocks=80166, us=108.16.165.144:1075, them=50.137.233.14:7685, peer=50.137.233.14:7685
Added 5 addresses from 50.137.233.14: 12 tried, 1585 new
Flushed 1597 addresses to peers.dat  0ms
received block 0000000000f0b227999f
ProcessBlock: ORPHAN BLOCK, prev=0000000075fe7ae1a6a4
CTxMemPool::accept() : accepted 4a705f9828 (poolsz 1)
received getdata for: tx 4a705f98286325802baa
received getdata for: tx 4a705f98286325802baa
received block 8264932c0e66bf98f21c
Misbehaving: 192.95.37.194:7685 (0 -> 100) DISCONNECTING
disconnecting node 192.95.37.194:7685
ERROR: ProcessBlock() : block with too little proof-of-stake
trying connection 192.241.222.16:7685 lastseen=0.9hrs
connected 192.241.222.16:7685
send version message: version 70000, blocks=80159, us=108.16.165.144:7685, them=192.241.222.16:7685, peer=192.241.222.16:7685
Added time data, samples 13, offset +6 (+0 minutes)
nTimeOffset = +5  (+0 minutes)
Moving 192.241.222.16:7685 to tried
receive version message: version 70000, blocks=80167, us=108.16.165.144:1076, them=192.241.222.16:7685, peer=192.241.222.16:7685
Added 6 addresses from 192.241.222.16: 13 tried, 1590 new
received block 00000000e9fbb8899d3c
ProcessBlock: ORPHAN BLOCK, prev=0000000000f0b227999f
received block 00000000ed8f40c6a41b
ProcessBlock: ORPHAN BLOCK, prev=00000000e20f701128db
received block 00000000e20f701128db
ProcessBlock: ORPHAN BLOCK, prev=0000000004964c128348
received block 0000000004964c128348
ProcessBlock: ORPHAN BLOCK, prev=00000000e6e3917a20ae
received block 0000000067292c0164fd
ProcessBlock: ACCEPTED
received block 00000000927f6995c39b
ProcessBlock: ACCEPTED
received block 000000008ba4e5ebe5d7
ProcessBlock: ACCEPTED

3.3.2 version of CGminer seems to have the same issue of displaying the wrong info in the accepted and rejected columns... going back down to 3.3.1... lol...

Yes, I noticed that too... 1.4.1 and 1.4.2 often have to be manually terminated from task-manager. Seems to hang if I don't shut-down my miners first, and then shut-down the wallet. I assume the network components are still talking to the miners, causing the hang.


This is more of a "security" and "value saver"... thing... having a minimum diff.

With a minimum diff (eg, system rejects anything faster, including attacks of natural and forced nature, made easy by letting diff fall to near-zero, while mining alone.) Having a minimum diff forces an attacker to have tons of individual power, if a coin ever falls below that point. Having a minimum diff also stops massive dumps that degrade coin value, causing people to stay away and never join it again. Dumps by those lucky three or 20 people getting tons and they just keep dumping them for less and less, until value for those who hold would take about a year to obtain the losses.

I am not saying it is a perfect solution... Just a realistic economic one that takes operation of the method into consideration. Plus, it allows coins to distribute fast enough to limit super-stacks of isolated forks. The network would still function, because of POS, which would dominate or sustain at that lower diff, if miners decided to stop mining at that point. Which they would not. Someone would mine it. Hell, there are people still mining sexcoin and it doesn't even have an exchange! (I still do, with some of my miners. Gotta have sexcoins!)

Currently the calcs show that a miner should get 270 coins per day for each 1 mHs. Yesterday and today (t least when on the correct chain) that is pretty much exactly what I have seen. I am running on Linux with cgminer 3.1.0, I know, it is a dinosaur, but my motto is if it isn't broken don't fix it.

As far as setting a minimum diff, if for some reason the coin lost most miners, for instance if the chain kept splitting or something (LOL) it concerns me it may be difficult to get them interested again. Personally I kind of like mining coins that are on the edge as the reward is higher if they pull through. However, as we all know, if they don't your hashes are gone.

With that said I don't think that CAP is really on the edge. Mullick has been great to address things and will get it all figured out. The coin also has a strong community and following, many of which are waiting on the sidelines to see what happens. The diff shows there is still plenty of interest in the coin at this point and has actually surprised me by staying as high as it has. Part of that is due to CoinWarz I would gues still having it listed at the top. You are 100% right that most don't do any math just see what is on top and mine it. (I guess that is better for us in most cases.)  LOL

I'll be interested to see the results you find with the older version of cgminer.

Go CAPs!

I can confirm that I've also had issues solo-mining on versions 1.4.1 and 1.4.2 yesterday and the day before. No mining today. I've definitely seen more rejects than ever before, but more worrisome is the inability to find any blocks whatsoever after a while, despite having several connections, being on the correct chain, and mining during periods of low difficulty. I have no way to distinguish between bad luck and some sort of issue, but after having mined this coin in the past successfully, something just doesn't seem right.

You have an interesting theory that difficult POW blocks may be competing against easy POS blocks to cause these POW block rejects. It would be interesting to check the rejected blocks against the accepted valid one to see what percentage have been crowded out by a POS block. I also wonder if there's anything in how a POS block is accepted/rejected that can be causing the client syncing problems. POW, POS, POW vs POW, POW, POW forking, will the network be able to consolidate the two forks and invalidate the shorter chain when one becomes longer? Maybe POS and POW blocks are treated the same in this regard, I don't know.

Someone mentioned this in an earlier post, but for the Devs - I also have the problem where my Windows client crashes sometimes upon exit, while at other times it just hangs on client shutdown until I kill the process. These problems are intermittent and have never occurred on any other crypto-client I've used.

My wallet is off for the time being, but will be turning it on occasionally to help wherever I can with using my screwed up PoS wallet.  So hopefully you won't be getting screwed up blocks from me.

Reverted back to cgminer 3.3.2, the last known "working" version that didn't cause issues with scryptcoins.

Will be nice to actually see the accepted and rejected qty again, instead of having to wait a day to guess if the network was screwing me or not. (I usually leave if diff drops below 0.65 on most coins. Because estimates of value become useless and they never display correct losses. Most losses are never reported or recorded, just thrown-out. Guess it never crossed their minds to actually try mining, and simply compare results with expected calculations, and see the reality of what you get. But then again, they are not in the business of making us money, only themselves. They like when we mine junk-coins that don't actually reward. Because they mine the ones that actually do. The #2, #3 and #4 coins on the lists. xD.)

Anyone bored and want to walk me through compiling one of these coins on windows, from source? Never used QT before, and not sure what they are using to compile them in the first place. But I am a fast learner.

Hmm... maybe it is this new cgminer that is causing the issues for me then... (Unless I am just real far from the source and you are closer to the ones generating POW and POS.)

My cgminer shows the diffs of the rejected and accepted blocks, not the quantity of accepted and rejected. (Bug in 3.3.4) I based my results off actual results, the end of the day yields.

At the half-diff, I am getting 50% less "accepted" in cgminer, and 75% more "rejected", as opposed to simply having 50% more "accepted" and 50% more "rejected". I am getting more solutions, but 75% of them are lost to another faster block.

I will fire-up the older cgminer, since this one seems borked. If it isn't displaying the correct values, I assume more inside may be borked too.

But the statement about having min diff for POW is still a strong conviction with me. It hurts no-one to do that, and only helps to ensure coin value stays high. (Even in the event of 90% of everyone leaving, where 3 people end-up getting all 100% of the coin, now they get the same amount as if there were hundreds of people. But if the coin came to that, it wouldn't matter at that point.) This is from experience mining fast coins, like fastcoins, sexcoins, mincoins, luckcoins, memecoins, anonymouscoins, etc... You can look at the charts and see the issues. You actually get more mining with higher diffs than with lower diffs, due to the major losses. On average. Unless you are uber-lucky and one of the sources of, "we just can't keep up with him", speeds.

I have not had any rejects today. I keep track of found blocks via the cgminer api and it matches exactly with the number of blocks in my wallet. The api shows no rejected blocks since about 6 hours ago when I reset things. I do not believe there were any this morning either, at least not enough to worry about. I just reset it again now before reading the above post but really have not had any issues with rejects or stales.

While I would agree we need to address the POS I do not see the diff as a problem at this point.

Just my $0.02 worth.

There are sooo many POS blocks coming in now... that they are killing about 50% of the attempted postings of POW blocks...

Enough that the diff is about half what it should be.

Please set the diff high for POS, until this is fixed, to stop those still mining POS from completely degrading normal mining. A few are still mining POS and getting tons of them faster now. Only having one with POS mining simply makes that one get all of them. It does not slow them down at the easy diff that it is set to.

I assume they are not being booted, because apparently there is only a few, or only one... as opposed to the massive collisions when most of us were still mining them.

I think we can all agree to that. Then we can all start mining POS again, and you can manually lower diff with each version. (That should give you an idea what to set for a diff adjustment for POS work. Even if it is something simple like 5% of POW diff + 0.02.)

Normally at 100K (1.53 diff), I get about 2-4 blocks an hour... Normally about 10% rejects.

Now, at the 40K (0.61 diff), I am getting about 1 every two hours, due to collisions {rejections}. Now about 75% rejects.

And the diff keeps falling to attempt to compensate, creating more POW to throw and try to beat the POS being generated. (There is no balance)

Speaking of limits, you might want to put a lower-limit on POW... like 45K (0.68 diff), which seems to be a choking point for most "fast coins" if they go lower. More collisions/rejects.

Pool is off again seems to have happened just recently

Looks like ill be spending all night on this again