I've had this happen too, client gets stuck on a block and chain carries on, but after I've resynced I see that I've still been earning BN/mining payments for hours after my client apparently got stuck.

Agreed on the IRC thing, I'd prefer the BCR app to be as lean as possible. If it got ditched would anyone miss it?

I added a border to the main window because I hated not having one    - but I could make it a .conf option?

Get rid of allowip and irc lines, add port=8877 and make sure it's open on your router. And make sure your OS or any firewall/antivirus crap you have installed isn't blocking your chosen rpcport too.

Running a BN is exactly the same as before - you need a 50000 BCR input with 15+ confirmations, a banknodeprivkey, and start it as before by unlocking the walet and typing 'banknode start'

To mine, you need one or more > 50000 BCR input(s) - however many of these you have, put the addresses for them in miningkeys.dat and start mining with 'setgenerate true 1' - currently you are restricted to mining 1 out of every 2 blocks, so to mine continuously you only need 2 > 50k inputs, however shortly this will be changed to 1 in 20 or 1 in 40, with the goal of everyone just running the minimum CPU cycles as there will be no point in wasting more power, since you are restricted to mining 1 block every 20 or 40.

The machine doing the mining can be a different one from wherever the wallet with the qualifying mining inputs is, as long as miningkeys.dat is present. Mining on something like a Raspberry Pi2 should cost you less than $0.02/week if you pay $0.20/kW/h for your electricity.

eg. you have 150000 BCR, you can start 3 BNs but those addresses wont be valid miningkeys until each BN has received a payment, making the total balance of that address greater than 50k. Or any combination of BNs and mining you like, although makes sense to be running both IMO as a single core/thread is all that's needed to mine, no more 1000W mining rigs.

Hope that helps.

Might have to change the math a little on the bids page, if the full 30000 BCR isn't going to bidders, but only 29982? Want to see it in action a few times before doing anything though.

@bitcreditscc: is the next superblock likely to work as intended without version-bumping old clients off?

Might have been a miner running a noncompliant build or mining software. networkhashps is up at 52 and diff in the hundreds again, someone's taking advantage of the only two consecutive blocks rule. Hopefully the next release will up it to 1/20 or 1/40 which will make it far less likely and more expensive to hijack a superblock.

Still possible for someone to strategically begin throwing hash at the chain just before the superblock though. There needs to be a way for any hijacked superblock to get rejected by the rest of the network, make it unspendable by the hijacker. Followed by automatic encryption of their home folder, ransom for the password payable to the BCR communal reserves.  

Done, crude, unfinished and ugly but it might help show if the problem is here or not.

@dragos - transactionview.cpp and transactionview.h  http://s000.tinyupload.com/?file_id=28914725737094427125 - can you swap these into your Win build and see if it helps with anything? Hides the history until you click the Show History button.

Couldn't get the Export button to show again (without a segdump  ) after hiding it initially but that can be looked into if this helps whatever prob Win users are having.

Boost libs - I have a hellish mixture of 1.55 1nd 1.54 

Berkeley DB 4.8.30

libpng12-0:amd64          1.2.50-1ubuntu2   amd64           
libpng12-0:i386           1.2.50-1ubuntu2   i386           
libpng12-dev              1.2.50-1ubuntu2   amd64           

libminiupnpc-dev          1.6-3ubuntu2.14.0 amd64             
libminiupnpc8             1.6-3ubuntu2.14.0 amd64           

openssl                   1.0.1f-1ubuntu2.1 amd64             

libmirprotobuf-dev:amd64  0.1.8+14.04.20140 amd64             
libmirprotobuf0:amd64     0.1.8+14.04.20140 amd64             
libprotobuf-dev:amd64     2.5.0-9ubuntu1    amd64             
libprotobuf-lite8:amd64   2.5.0-9ubuntu1    amd64             
libprotobuf8:amd64        2.5.0-9ubuntu1    amd64             
protobuf-compiler         2.5.0-9ubuntu1    amd64             


libqrencode-dev           3.4.2-1           amd64             
libqrencode3:amd64        3.4.2-1           amd64             
qtbase5-dev:amd64         5.2.1+dfsg-1ubunt amd64             
qtbase5-dev-tools         5.2.1+dfsg-1ubunt amd64           
qtbase5-private-dev:amd64 5.2.1+dfsg-1ubunt amd64             

qttools5-dev              5.2.1-8build1     amd64           
qttools5-dev-tools        5.2.1-8build1     amd64           

curl                      7.35.0-1ubuntu2.5 amd64             
libcurl3:amd64            7.35.0-1ubuntu2.5 amd64             
libcurl3-gnutls:amd64     7.35.0-1ubuntu2.5 amd64           
libcurl4-openssl-dev:amd6 7.35.0-1ubuntu2.5 amd64             
python-pycurl             7.19.3-0ubuntu3   amd64           
python3-pycurl            7.19.3-0ubuntu3   amd64             

I'm not sure what you mean - there were no additional dependencies needed. I possibly had to #include some QT widgets that weren't needed previously.

IIRC, I recreated the balances bit at the top of overviewpage in transactionview.cpp. (GUI parts are coded in the .cpp, there's no transactionview.ui form, and the code to display the balances I lifted from overviewpage.cpp.) Didn't touch the transactionview stuff at all apart from moving the Export button from where it was down at the bottom to the top to save vertical space. Then just pointed overviewaction in bitcreditgui.cpp to transactionview instead.

Is there an issue with it on Win? Never gave me any grief on linux.

Try:

addnode=91.230.123.101:8888
addnode=91.230.123.11:8877
addnode=82.211.1.181:8877
addnode=91.230.123.101:8877

Can diff be made 'harder' (or slower) to increase than to decrease? Or have the client cap hashespersec and stop mining if whatever threshold is breached, but that presents another enforcement challenge.

I'm still struggling to see what useful purpose PoW serves in the current BCR model that can't be better (and surely more easily from a coding and maintenance POV?) served by BN-only consensus without the extra complicated cog in the machine.

I think chainz counts everything as mined-by-p2pool for BCR regardless. The BN address that mined the block has the needed funds, and by the look of the IP's in the BN list whoever owns that address also has another 7/8 BNs, might even be bitcreditscc. 

I haven't had the same problem as you though with the client crashing after importing any (DASH) privkeys. Haven't made any bids with anything else yet. That libpng error is just QT moaning about some icon it doesn't like the look of, it does that anyway.

Looks like 6BWBUastjKmn4KnPMNPqfKdF36JgbgE8qM was the lucky miner, no payouts to bidders:

I don't think the other miningkeys are used yet as the rule still just 'not consecutive' rather than the eventually intended 'one in twenty?'

Heh, thanks for doubling the networkhashps/hashespermin vars.

getmininginfo
{
"blocks" : 210375,
"currentblocksize" : 1000,
"currentblocktx" : 0,
"difficulty" : 0.00000032,
"errors" : "",
"genproclimit" : 1,
"networkhashps" : 11.81779068,
"pooledtx" : 0,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 5.48705968
}

Hmm, I'm stuck on 210285:

getmininginfo
{
"blocks" : 210285,
"currentblocksize" : 1677,
"currentblocktx" : 3,
"difficulty" : 0.00000002,
"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues.",
"genproclimit" : 1,
"networkhashps" : 0,
"pooledtx" : 3,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 5
}

Diff is nice and low here...  

Right now you only need 2 x 50k+ addresses to mine continuously, just put both addresses in miningkeys.dat. When it increases to 1 in 20 (or whatever) you'll need 20 x 50k+ addresses to mine continuously.

Without banknode.conf working, having more than one exactly 50k input in a wallet screws up starting your banknode, as the client seems to select a 50k vin at random, not necessarily the one that matches your banknodeprivkey.

I think things as they are now will do, it allows users to decide which income stream(s) they prefer.

You can run as many miningkeys as you can afford off a Pi2 or similar, appx. running cost nothing - 1 core of a Pi2 uses well under 500mW at full load, so take your electricity cost per kW/h and divide it by 2000, it doesn't amount to much even if you're paying European prices... or you can stick 10+ BNs on a $4/month 2GB RAM VPS... or do both, or whatever combination you like.

Could this be made dynamic?

eg. 1 / ( BN count ) or 1 / ( BN count * 0.8 ) to give 20% leeway?

I appreciate that it's not only BNs mining now, but anyone with >50k BCR, but just a thought; maybe in future a count of miningkeys could be kept and used also, or maybe mining will be made BN-only in future versions.