The network diff reported by cgminer varies depending on the version.  The older ones like 3.6.6 would say the target share difficulty, i.e. 4.5k so that means if we find a share that is higher than 4.5k, it is a solution to the block.  The newer 3.7.2 only reports the network difficulty, i.e. 0 for anything from 0.0000 to 0.9999 - doesn't show it as a share difficulty.  Personally I prefer to know the target share difficulty.

I forgot to mention what the earnings estimate would be for a 2MH miner.

I am getting about 220NBL average a day, and my hashrate is about 2.2MH, so estimate 200NBL a day per 2MH.  This is about 0.011 BTC at current exchange rate.

As the pool gets larger, we don't necessary get more because more blocks are being solved, because we are sharing the results with the other miners - but that is my estimated return until the difficulty readjusts.

The assumption is that when the difficulty readjusts it will be at a target difficulty that allows 20MH to solve a block on average in 2.5 minutes.  At that rate  we start to get 2,880NBL a day.  This should last for about 2016 blocks until the next difficulty retarget - I am not sure what happens when huge miners join the party, but we should still be solving more blocks, so hopefully we can maintain this earning rate - I am optimistic of making about 1BTC every week or so, aren't you?  Maybe someone can check my numbers.

[Edit]  Just a couple of more points.  Most 2MH miners can mine other coins and get a return of 0.02BTC a day on average - sometimes more depending on the coin.  We don't have to be on the pool all the time - by all means, mine other coins from time to time, to keep your earnings up - just devote some hashrate to the pool and we can keep this coin going.  Don't forget - if all mining stops, the coin effectively dies because no transfers can take place, no confirmations etc, other than what is within the exchange.

If you read what I was saying a few posts down from yours - that is where I was making the case.  Since then I have been checking the pool block stats and have the following:

At block 39144 we were averaging 5.5 hrs per block, pool hash rate around 2.5MH - at current rate 9 months before difficulty retarget.
A week earlier when I was the only miner on the pool - hash rate around 2MH - average was 8 hrs per block - would have been 1.3 years.

In the past 9 hrs, we are at 39149 - there is or must be a solo miner out there who has solved the last 4 blocks - probably 4-5MH.

If we can get to around 10MH on the pool, we should be looking at solving 18 blocks a day - estimate 65 days to difficulty retarget.
If we can get to around 20MH on the pool, we double that, and reduce the time to about 32-33 days or so - 1 month+ which I believe is achievable.

The gains for us, if we can get enough support is explained previously that the target block time is 2.5 minutes, so our pool instead of solving 4-5 blocks a day now, we could get 576 blocks - the equivalent of 1.5BTC a day.  What does this mean?  A 2MH miner would get a return of about 0.15BTC equivalent in NBL - right now if I mine other coins with my 2MH, I get about 0.018BTC a day, so for me I think it is a good investment.

Now, I don't claim that everything will be sweet - when the difficulty readjusts, we are sure to have other miners join in - however if we are at the beginning, we reap the rewards first.  The danger is that we cannot keep the pool small and end up in the same situation with mining after 2016 blocks driving the difficulty very high again - but with mining, it is always a risk.

Ok - who's in?

My client is connected to 1 or 2 most of the time, use these:

addnode=54.200.132.23
addnode=109.10.236.54

also, you can add my client

addnode=mentat.cable.nu
or
addnode=124.189.53.150

since mine is a dynamic address from the provider, I registered with a ddns host to use the name - try using both.

Another thing, if you have the connect statement in your conf file, remove it.

Actually the translation is that "Chinese now mine it".

That is not advisable.  Also it will not work unless we only solo mine, since the wallet would have to be changed on the pool servers as well.  I suppose that there was never an expectation that the mining power would more or less disappear - which is sort of what happened.  With the release of new coins - many of the big speculative miners will jump onto a new coin, get a bundle then go onto the next coin.  They wait for the coin to hit an exchange, then sell out.  This then leaves a lot of coins in situations that the difficulty is high, and with little mining power.  However NBL still is worth something - more than some coins anyway, so it is worthwhile mining for a steady income.  I am aiming with my 2MH/s to get about 0.02BTC equivalent in coins a day.  With NBL I am not reaching my target, but am prepared to keep going.  Once the difficulty drops in 1176 blocks - we should be able get around 0.1BTC a day I expect if the coin value doesn't drop.  When will this happen - if we get a few more miners, maybe get to 20MH/s on the pool, we can do this in about 1 month.  If we can't - then it will take longer.  Don't forget that the target block time is 2.5 minutes, so once the difficulty retargets, we are aiming at about 576 blocks per day or 28,800 NBL a day or something like 2880 NBL for every 2MH/s miner - current value is 0.15BTC.  This is optimistic and might not work for very long before people find out about it and start mining it again - but if we are there at the beginning, we have a head start.

Great - thanks.  Let's keep it up - there are 4 miners at the moment, so blocks should be getting quicker.  Currently on 39143.  That block 39139 took 19.5 hrs - I almost gave up on it, but glad I persisted.  Let's all keep this coin alive, although it looks like Cryptsy isn't confirming deposits - one I have is stuck at 8 confirmations for the past 4 blocks.

JL0zNYAN

Hi - we need more miners on nbl.pnwminer.com - I tried solo mining, but gave up when I realized that solo mining requires 120 confirmations, now I am back on the pool which only needs 20 confirmations.  The current block is 39139 - been working on this for the past 8.4 hrs, we need more miners to speed this up - only 1181 blocks to go before the difficulty retargets to something a lot more reasonable.  I know this is a big ask, but if someone has spare mining power - NBL is still a good earner, but we need more miners so that transfers and deposits don't take forever.

[Edit]  This is just a long block, usually it has been taking around 2hrs per block, but if we get more miners, we can reduce the time.  Transfers and deposits generally need 8 or so confirmations, meaning 8 blocks to be solved - currently taking a day to confirm but more miners means more hashing power means quicker confirmation times.

I don't know if this is that simple to fix.  I was perusing the blockchain.  It seems to be that block 411228 is that block that caused the problem - it seems that the time on the wallet client was ahead by about 1 hr, which doesn't seem possible because usually the clients do time checks with each other when receiving block version messages (cannot really say for Orbit client, but does happen for other clients).  Then the next block 411229 came from a client that was on the correct time, but due to this negative time, the difficulty changes dramatically.

Block 411225 December 30, 2013, 7:55 pm Diff 0.1701947
Block 411226 December 30, 2013, 7:56 pm Diff 0.17276514
Block 411227 December 30, 2013, 7:56 pm Diff 0.17286038
Block 411228 December 30, 2013, 8:56 pm Diff 0.17353002
Block 411229 December 30, 2013, 7:58 pm Diff 0.05879355
Block 411230 December 30, 2013, 8:07 pm Diff 0.00024414 Zero block nonce

Difficulty is increasing normally, so looks like single block difficulty retarget, but 411228 is reported by a client at 8:56 pm, so it looks like the mining power disappeared, but in fact it hadn't - however due to the long time between blocks, the difficulty is lowered.  Block 411229 comes along - now here is the interesting thing - the block time should have been checked and rejected because it came before the last block time, but it is allowed to be incorporated into the blockchain.  After that is when the block nonce is zero for future blocks - something else that needs to be looked at.

Ok, so it appears that there might be several different occurrences.  One is the difficulty retarget due to an incorrect time client (maybe malicious).  Second is allowing a block to occur before the previous block (again - it could be that someone has hacked the client to remove this restriction to allow it to occur, or maybe just an oversight in the client code).  Third is this zero nonce - that I don't understand as yet, but must be causing a problem.

I looked at the blocks using the Orbitcoin Block Crawler https://andarazoroflove.org/explorer/orbitcoin/block_crawler.php

Now the developer would need to look at this issue, maybe we have to remove 411228 from the blockchain or cause a hard fork to occur.  The current block appears to be 411512 so we are not looking at a lot of coins, but there will be lots of transactions that have confirmed and now - what happens to them!

Patching the client is another thing - it looks like two (or more) things, the retarget problem, and the block time problem - then examine the zero nonce and see how that is happening.  The dev is saying that it is an attack on the coin and doesn't think the retarget change is needed - and he could be right, however the block time problem would allow the blockchain to continue, i.e. reject finding of blocks until the actual time catches up with the bad block time - but I think both is needed.  What happens if a client was 1 year ahead and reported a block - that would stop blocks from being mined for a year, not acceptable.  Then confirm that the clients does check time sync so that we avoid the issue of a client with the wrong time, i.e. not accept blocks from clients where the times do not within reasonable limits.

Anyway, my ten cents worth - I don't mine or trade Orbitcoin, but I was researching it with a view to mine, but then found out about this issue.

Happy New Year!

I don't see much mining activity on NBL at present.

The last block solved was 39119 - very slow going.  The block has been broadcast, but I don't have any incoming confirmations as yet that the network has accepted it.  I think this might be due to too few operational nodes - maybe they have shutdown for the holidays.  I was looking at a pool but the nbl.pnwminer.com pool seems to be behind at 39117.

A few things I have done, I configure my Windows Firewall to block nibble-qt.exe from accessing certain outbound tcp ports.  After I did this and continued to block ports I find that my client now does not try to synchronize with other coin's blockchains.  I realize that this is really unnecessary as other blockchains cannot be incorporated but it does reduce the network traffic and reduce the cpu usage as the received blocks are not being orphaned all the time or being rejected.  I am blocking these ports, 2543, 4401, 7785, 7999, 9333-9337, 9527, 9556, 10333, 10442, 11081, 11351, 12128, 13809, 15678, 19667.  I realize that I could just block port ranges, but wanted to keep them individual - I check the debug.log file from time to time whenever I see it trying to sync incorrectly then block the port again etc.

Now I seem to only be connecting to one other node 54.200.132.23.  My client does connect to 70.79.24.157 but that node does not respond with a version message.  My node address is still 124.189.53.150 - so if there are any other working clients out there, can someone let me know.

Hi - Happy New Year to All!

mkimid - Often clients will generate the mined coins from another address which is associated with your wallet.  Some clients will tend to use the same address or one of a small number of addresses, and other clients like the Networkcoin client will always generate a new address for the mined blocks.  I believe that these addresses are associated with your wallet private key, because I have experienced in other coins that if I generate a new address for receiving transactions, one of the addresses used for mined coins is used.  Then I find that the mined coins use another address and so on.

I was going to insert a screenshot here to illustrate, but for some reason, I can't work out how to do this.  The Peoplecoin client uses a few different addresses - there is no apparent order in which the addresses are used.  I have only solo-mined one block of Grain so cannot say what it will do with multiple blocks, but if you are seeing each mined block with a different address, then it might be safe to say that a new address will be used for each mined block - like Networkcoin.

I also had a look at the blockchain - and saw how the amounts would split from address to another address when transactions were sent out to other addresses.  It did look suspicious but in the end, I decided that it must be normal operation (at least for Grain).

I did solo-mine one GRA block.  This was 42846.  I was looking at this because in my wallet, when I view the list of transactions, it shows that it came from an address which was not my actual address.  This is the address that the blockchain shows as being credited with that particular block.  I understand from other altcoin clients that this can be normal, i.e. a mined block sometimes is credited to the wallet address, but sometimes comes from another address.  These other addresses are in fact addresses associated with the wallet which are not normally visible.

You would find that if you add another address, it will pick up most likely one of those other addresses that were associated with mined blocks.  I saw this happen with PeopleCoin for example which I had been solo-mining with a lot of success a couple of months ago.  The mined blocks would pop up in my transactions with different addresses.  When I added a new address - it used one of those addresses, then the mined blocks would appear from another or other address and so on.

As to why sending an amount, would cause the balance to shift to another address - hard to say why, but it is the same wallet anyway.  Maybe this is one of the anonymizing features so that it is hard to track balances of wallets, perhaps.

I have been persisting with the Nibble/Nybble mining - current block being worked on is 39117.  However I am finding that the client is making connections to not just litecoin but also worldcoin and other altcoins.  This comes about because the client code is based on the original Bitcoin client - future developers should really change the subversion to make it distinct and then check for this when making peer connections.  This should avoid peering with incompatible altcoin clients.  An example of what I mean is:

09:17:45 getpeerinfo

09:17:45
[
{
"addr" : "54.200.132.23:8550",
"services" : "00000001",
"lastsend" : 1388441860,
"lastrecv" : 1388441839,
"conntime" : 1388395424,
"version" : 60001,
"subver" : "/Satoshi:0.6.5.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 39113,
"banscore" : 0
},
{
"addr" : "31.185.159.126:9336",
"services" : "00000001",
"lastsend" : 1388441857,
"lastrecv" : 1388441657,
"conntime" : 1388420589,
"version" : 60002,
"subver" : "/Satoshi:0.6.4.4/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 140029,
"banscore" : 0
},
{
"addr" : "176.25.115.107:11081",
"services" : "00000001",
"lastsend" : 1388441862,
"lastrecv" : 1388441556,
"conntime" : 1388425483,
"version" : 70001,
"subver" : "/WorldcoinFoundation:0.8.5.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 11583,
"banscore" : 0
},
{
"addr" : "95.31.7.14:8550",
"services" : "00000001",
"lastsend" : 1388441830,
"lastrecv" : 1388441834,
"conntime" : 1388434279,
"version" : 60001,
"subver" : "/Satoshi:0.6.5.2/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 39116,
"banscore" : 0
},
{
"addr" : "86.186.14.143:11081",
"services" : "00000001",
"lastsend" : 1388441816,
"lastrecv" : 1388441830,
"conntime" : 1388441336,
"version" : 70001,
"subver" : "/WorldcoinFoundation:0.8.5.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 30194,
"banscore" : 0
},
{
"addr" : "79.120.114.167:11081",
"services" : "00000001",
"lastsend" : 1388441859,
"lastrecv" : 1388441863,
"conntime" : 1388441343,
"version" : 70001,
"subver" : "/WorldcoinFoundation:0.8.5.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 5843,
"banscore" : 0
},
{
"addr" : "123.52.1.56:9333",
"services" : "00000001",
"lastsend" : 1388441864,
"lastrecv" : 1388441860,
"conntime" : 1388441487,
"version" : 70002,
"subver" : "/Satoshi:0.8.5.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 488351,
"banscore" : 0
},
{
"addr" : "84.245.71.31:9333",
"services" : "00000001",
"lastsend" : 1388441845,
"lastrecv" : 1388441858,
"conntime" : 1388441673,
"version" : 70002,
"subver" : "/Satoshi:0.8.5.1/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 488351,
"banscore" : 0
}
]

Here we see WDC client on port 11081, LTC client on port 9333, and FTC client on port 9336.  I realize that we cannot restrict based on port 8550 alone because some clients may be forced to use different ports due to local network restrictions, but maybe the "subver" could be used to indicate "/Nybble:0.6.5.3/" assuming 0.6.5.3 would be a later version to 0.6.5.2 - then we could make peer connections based on looking for Nybble etc.  I don't find this problem happening with other altcoin clients, and I do run quite a few of them from time to time - so can we get this fixed?

What about the PoS on the pre-mine wallets?  Could this be where it is coming from?  If so, maybe get those wallets closed.  We can't all close our wallets otherwise the whole network will stop 

So basically why I did the run through the block chain is that if a theoretically huge solo miner was working away, we should see PoW blocks being taken by this miner - and those 50 blocks showed that there wasn't one then.  Not that there isn't one - but within that sample, he wasn't there, so chances are he doesn't exist.  Hence the smoking gun points to PoS as the culprit.  So, next question - how do we fix it?

Jollyburner, I think I would have to agree with you.  I had a look at blocks from 56071 onwards to check the addresses that payments were going to:

56071   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56072   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56073   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56074   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56075   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56076   9EcmNqQmiEbo5G4s2e91dzGdL9KRjenrQ9
56077   9AJ5YhCPkTKSXNx9fFobmkayp2cBUqFUNZ
56078   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56079   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56080   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56081   9StWjUHMHt3FfQXMKxtcDNRr3h26cKQKtQ   =livechains
56082   9T5EUuj1f24jRUWfbKwrRtWbMVzr5UZF3A
56083   9T5EUuj1f24jRUWfbKwrRtWbMVzr5UZF3A
56084   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56085   97mHyuMsZC3RyU9p3JiX5xyDpYXDZZUFdj   =forkpool
56086   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56087   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56088   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56089   9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck
56090   97mHyuMsZC3RyU9p3JiX5xyDpYXDZZUFdj   =forkpool
56096   97mHyuMsZC3RyU9p3JiX5xyDpYXDZZUFdj   =forkpool
56109   9StWjUHMHt3FfQXMKxtcDNRr3h26cKQKtQ   =livechains
56120   9EX5G97HZMgZaTLdonGzNvs3ANDpBpiV47   =other_miner

Most of the payments are going to 9RasWHQWcNfcS86uk4pHC3v5KMafFyYUck which I guess is a PoS recipient.  Only 6 mined blocks in that lot of 50.  I gave up recording the addresses and ended up just looking for mined blocks.

This pool also is working away - it is multi-coin switching to the most profitable coin, or can choose to mine a particular coin.  Has a good percentage of JKC network - I like it.

The pool changed to new hardware - now found at

http://coin-base.info/jkccoin/index.php and uses port 3457 only.  Has a small percentage of the network hash - currently 88MH/s relative to 491MH/s network.

Hi all, here is a list of nodes that I found my client was connecting to - for the past couple of days.

addnode=77.251.56.232
addnode=54.200.132.23
addnode=194.79.23.98
addnode=95.31.7.14

if you want to try my client, it is dynamic but at present would be

addnode=124.189.53.150