Mine on multipool or cryptsy pools... they both have the correct chains, until you get all setup.

You may have to keep disconnecting and reconnecting, until you get the right one, or if it hangs while downloading the chain from the connections. (Deleting the peers file AFTER the client shuts-down. If you delete it before, it saves it when it does shut-down, defeating the purpose of deleting it.)

Balance: 19014.479855
Stake: 30.03

(0.01 block just confirmed 25-confirms)
Balance: 19014.489855 (0.01 gained)
Stake: 30.02 (0.01 stake removed?)

(0.01 block just found 0-confirms)
Balance: 19004.489855 (-10.00 moved to stake-waiting)
Stake: 30.02 (Pending 6 confirms?)

(0.01 block just confirmed 25-confirms)
Balance: 19014.499855 (0.01 gained)
Stake: 30.01 (0.01 stake removed?)

(0.01 block just confirmed 0-confirms)
Balance: 19004.499855 (-10.00 moved to stake-waiting)
Stake: 40.03 (10.01 stake added from 6-confirms prior stake-waiting above...)

(0.01 block just confirmed 25-confirms)
Balance: 19014.509855 (0.01 gained)
Stake: 30.02 (0.01 stake removed?)

....

I thought it would do this...

Stake: 10, 20, 30, 40, 50, 60.... etc... keep climbing until 90 days, then go... 3000, 2990, 2980, 2970 (as they get unstaked)... unless more were added, then it would stay the same, roughly... 3000, 2990, 3000, 2990, 3000

While the rewards would be... 0.01, 0.02, 0.03, 0.04.... up to 20.34 as more and more accumulate. (With those going directly to the balance, not back to stake.)

I am finding so many... so they are popping in and out real fast. But if I found them slower, they would only get to about 40 or so... then return to 0 again soon. But the reward is not giving 0.005% of staked, just 0.005 of the blocks of 10+10, not the staked total.

Not that I am complaining, as getting 0.005% is a nice bonus that seems to reward fast. It just seemed like it was going to be operated another way. By all the sample documentation that was provided.

0.005% of 20,000 is about 100 CAPs... which is great. I will have that return within a month, at this rate. Better than the lotto-style it seemed to be at first, where I wasn't getting any POS for a month.

YES, you are way off...

Let the pool operator know... he is slacking.

Ok, here is what is happening...

Ten coins become staked on the 0.00 blocks... (Not sure if it REMOVES 10 coins or not.)

Then on the 0.01 blocks, 10 or 10.01 coins move to staked, but move back to normal coins after confirmation? (Every other one has the 0.01 added to the 10 it moves.)

In the process, every other 0.01 block produces 0.01 coins as a bonus...

This is NOT how I thought it was going to work... At the most, I will have only about 100.10 coins staked at any one time. I thought they were all going to move to stake, and only the "rewards" would instantly become coins, and after 90 days, the staked coins become unstaked...

It is more like 25 blocks not 90 days, and the coins become unstaked and move back. (Thus never rewarding more than 0.01 or 0.02, at the moment. They don't stay long enough to accumulate more than that micro-amount, before moving out of stake.)

Eg... we get 0.005 per POS block, essentially... it has nothing to do with the number of unspent coins, or accumulation of coins in stake. (As far as it is acting now. When I had 70 I did not get 0.07 reward, as implied, or 0.03 even...)

Current block-height check...

I am mining on 77359 @ 10:20 PM (GMT -5), same as on http://bottlecaps.kicks-ass.net/block_crawler.php

This still correct? All connections are version 70000, except one IP: 192.241.142.48:7685.

Getting TONS of POS-reward blocks. (Few actual POS-changeover blocks. Ones that convert 10 coins to stake.)

Though, the numbers don't add up...

4 POS blocks 0.00val = 40 staked coins...
53 POS-reward blocks 0.01val = 0.53 staked rewards?

Total should be 40.53 staked? I have 40.02... it went down again from the 70.06 I had... odd.

Oldest confirm is 488 confirmed, my first POS 0.00 block.

We really need a "Stake reward" column, to show that coins have moved from stake. That, or a running-total in the list of transactions, to show "Mined", "Staked", "Rewarded", and "Deposited"... or something like that.

As I type, my staked coins just dropped to 30.02... Am I loosing coins?

I have an issue with the latest CGMINER...

Instead of showing the number of "Accepted" and "Rejected" A: 2 R:1 HW: 0... it shows the "last diff" of the last accepted block for accepted and rejected, eg, for my scrypt-coins it shows...
A: 70687 R :68799 (Wow, great, 70687 accepted blocks and only 68799 rejects! From submitting two blocks!) lol

Those are the DIFFs of the coins I am mining, 70.7K and 68.8K were the two found.

Why did this change, and how do I get it back to show the NUMBER of accepted so I can see when ACCEPTED vs REJECTED, to gauge the effectiveness of the coins I am mining. Without knowing the number of accepted coins, that stat is useless. Why would we care what the DIFF was, in the stats?

This is not what it should be showing us... something is wrong... as per the readme and sample screen-shots...

I also notice it is throwing-off other stats... hope this throw-off isn't going to change the way the program makes judgement about connections...

Note: This is the windows compiled version 3.3.4, mining bottlecaps at the moment version 1.4.1.

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

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

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.

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

I am getting bonus blocks paid-out. Everything seems to work fine for me. The only thing I still wish to see is this back on the exchanges. Even if it is a private exchange, setup by some of the people using the coin for selling goods.

Someone should still talk to the owners of all the sites listed on sharks-lagoon and the other flash-games and virtual sites. Not to mention the many, many popular Anime, Manga, Hentai, and other high-demand sites. They are constantly looking for other forms of collection that is not related to credit-cards, pay-pal, or e-gold.

The problem is not that we don't see the correct chain and connections...

The problem is that they are not letting us connect... (I have tried every connection manually, restarting 38 times, there is nothing to delete, because they never give us anything to delete. Except when the connections eventually connect to those four that are talking, with the shorter chain. My IP is not banned, I have tried from many connections and IP's and proxies.)

As per my above post. Either they are killing our connections, or our wallets are killing their connection.

I assume our wallets are rejecting the "-1" block-height, which is what our clients are translating that data that they are sending us as. (Usually an issue with a terminator that is incorrectly formatted or invalid ISO:chrs, eg, formatting as a 64-bit, but trying to read it as 32-bit, or by using CR or LF, when an expected "new line" in windows is CRLF. Some windows will attempt to "fix" that error, other windows will not. If that is the issue, other than malformatted raw data. Also, ISO conversions that we do not have the correct "format" for, which turns things like ISO:2345 into a "Q" instead of a "*", unless we have that language-type installed. That is only an issue if a program is compiled on a computer with a unique language-pack that other windows does not have, like chinese, japanese, french, italian, spanish, greek, etc... Only happens on HOME versions of windows which MS does not allow language-packs to be installed, that are non-standard. Not an issue on linux or mac, as they come with most ISO CHR formats.)

Please check the RAW DATA they they are sending, and locate why some of us translate that data as "-1" block-height and a bunch of nulls, and why other clients can correctly translate that data into the correct data, if they are sending us the correct data.

Every single IP with the "correct chain", is rejecting my connections, or is feeding my wallet this invalid data. So nothing ever gets downloaded, because there is no connection being sustained.

They don't even connect to give us the blocks that everyone-else has. Only the connections which have the short chain are feeding us that forked chain, which obviously is forked because they are not being fed the same thing we are not being fed... the blocks.

Same one as I have... but those connections are not working, the wallet is just going hyper disconnecting and joining tons of rooms, looking for more connections.

This is getting more strange with each day that passes. lol.

I am going to redownload both exe's and compare them. Though I doubt we are all corrupted, as others are still getting stuck on those four connections.

UPDATE: No luck... both still have the same results.

The only other thing I can think-of, is "home" does not offer language-packs, other than default. Is it possible someone in the chat-rooms is broadcasting ISO:Chrs that home users can't "translate", without having the language-packs. (If it is not a "terminator" issue, it may be a ISO:chr format issue.)

Win-home only has a few languages. Windows fails to convert other ISO standards, unless you get the ultimate or pro versions. (Similar things happen on japanese and chinese websites and programs.)

EDIT: I can think of one more issue... could my IP be rejected, from being listed with a banscore? IP's are not fixed, and mine rolls every few days. How do you check something like that? (If they are rejecting my connection, because of a banscore... I have no clue who had this IP before me. IP banning is as useless as cookie-banning. lol. It would be odd that I was IP-banned from every single correct chain, and IP, except the four with the wrong-height, which is the four I was mining on for weeks, without issue, and still connect to.)

What version of windows? (Mine is Win-7 home 64-bit.)

Also, are you using the v1.4.0 version? If yes, do you remember which link? (One of the links might have screwed-up compile settings. Like optimization and removal of error-checking or out-of-bounds checking.)

"startingheight" : 73204

Seems like the right height...

I assume you are not using the windows compiled wallet v1.4.0...

PM me, and I will send the log-file of a fresh connection to that list... From my windows client. It shows every connection connecting, then terminating, over and over, entering and exiting rooms, looking for connections which are in that list, and others. All with the same results.

Here is what is happening to my wallet... This is the reason many of us can not connect...

That long list of connections (I assume all linux compiles)...
Are all feeding this to us... (windows compiles v1.4.0)
{
"addr" : "199.192.205.46",
"services" : "00000000",
"lastsend" : 0,
"lastrecv" : 0,
"conntime" : 1376446605,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}


That is one of the connections, and they are all doing that, all IP's listed below, without xxxx's... from the list on the block-explorer... It connects for a split second, which is how I captured that info, then instantly disconnects us.

Notice VERSION: 0 and STARTINGHEIGHT: -1 and SERVICES: 0 and SUBVER: "", all null I assume, except the block, which may be null -1.

All connections are killing us, or we are killing all these connections...

We can't download the chain, because there are -1 blocks to download. (They are not speaking to us. Us windows users, I assume. WG, the windows compile is screwed-up. We connect fine when we are all on the same chain, win/linux... But now the correct chain seems to be only on linux, and it is not speaking to windows wallets. Check your "terminators"... windows is CRLF not just CR or LF, like linux or mac. Or the linux compiles are all botched, and not accepting windows data.)

These are the only ones speaking to us... (Even when we add the big list from the block-chains.)
[
{
"addr" : "70.98.114.237:7685",
"services" : "00000001",
"lastsend" : 1376447163,
"lastrecv" : 1376447164,
"conntime" : 1376447105,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "192.241.222.16:7685",
"services" : "00000001",
"lastsend" : 1376447118,
"lastrecv" : 1376447121,
"conntime" : 1376447117,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "199.180.115.100:7685",
"services" : "00000001",
"lastsend" : 1376447132,
"lastrecv" : 1376447133,
"conntime" : 1376447130,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72115,
"banscore" : 0
},
{
"addr" : "70.79.24.157:7685",
"services" : "00000001",
"lastsend" : 1376447348,
"lastrecv" : 1376447378,
"conntime" : 1376447343,
"version" : 60008,
"subver" : "/Satoshi:0.7.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 72116,
"banscore" : 0
}
]

Get one of those with the correct height, and we will all be in sync again...

NOTE: I have removed them from my list, and deleted peers, and the block-chain files... they always keep reconnecting to these four IP's...

Below is the long list (I have it setup to 100 connections, but the wallets only allow 8.) None connect, except the ones I xxxxxx'ed out... Which all have a block-height of 72115 now.

splash=0
server=1
gen=0
testnet=0
daemon=1
maxconnections=100
listen=1
xxxxxxxxxxxxxxxreservebalance=1000000

addnode=2.81.165.221
addnode=5.167.120.71
addnode=24.177.66.222
addnode=46.4.74.197
addnode=50.137.233.14
addnode=54.232.197.215
addnode=60.242.225.227
addnode=69.85.86.195
addnode=70.69.238.84
xxxxxxxxxxxxxxxxxxxxxxxaddnode=70.79.24.157
addnode=70.98.114.229
xxxxxxxxxxxxxxxxxxxxxxxaddnode=70.98.114.237
addnode=72.190.53.101
addnode=80.198.94.98
addnode=82.46.148.115
addnode=82.196.15.206
addnode=88.195.204.114
addnode=91.78.85.221
addnode=92.5.104.42
addnode=92.24.172.199
addnode=95.25.114.165
addnode=105.236.213.165
addnode=106.186.30.13
addnode=106.186.115.58
addnode=106.187.100.78
addnode=108.16.165.144
addnode=114.198.5.175
addnode=172.250.241.106
addnode=174.52.220.23
addnode=176.34.210.88
addnode=183.235.214.148
addnode=186.95.162.209
addnode=188.165.194.201
addnode=188.165.211.65
addnode=190.19.238.43
addnode=192.241.148.204
addnode=192.241.216.151
xxxxxxxxxxxxxxxxxxxxxxxxaddnode=192.241.222.16
addnode=192.241.222.102
addnode=199.192.205.46
xxxxxxxxxxxxxxxxxxxxxxxxaddnode=199.180.115.100
addnode=199.180.115.125
addnode=208.54.70.131
addnode=213.141.109.154

P.S. Exchanges might want to halt delivery and acceptance for a while, until they figure out why the programs they are running, are isolating themselves from others on the network. You will be exchanging coins that are going to disappear soon.

Hard-coding blocks from those exchanges, on a network that is constantly isolating itself will NOT help.

Mining on the high diff chains will only work if you keep constant miners on there. Once they leave, the new miners will be connecting to the chain that is actually talking, the ones that you connect to without addnodes and the ones that are on the original addnodes listed on the front page.

Though, since the change, those four listed are not sending the block-chain to us, only telling us that they have a bigger block-height. Which is just useless if you want your chain to grow. It can't grow if you don't tell us what to build off of.

See above post...

Yes, deleted, and still being rejected... Thus, unreliable...

The database should be split into 2 parts... (Hard-coded archives), and (new)... This would stop all the useless redownloading every time. It would also allow it to "fix itself" instead of having to redownload, if a fork is detected. (Hard-coded matching the hard-coded block-height), (New being anything above that last coded block-height.)

The forks are being detected... It sees I am "caught-up" on 72044, then after a while it sees the other height, but never downloads anything, just saying, "out of sync", but still mines away.

It is a "speaking" issue, or an ISP-blocking issue, not a listening issue... (Unless the wallet just can't "undo and repair", going backwards to the point of the fork. But I have downloaded five times now, all the same result... I am going back to mining the one chain that actually IS reliable, by way of communicating it's blocks for it's block-height. It WILL eventually catch-up and tower over the non-speaking chains that are running solo, or in "small groups".)

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.

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.