I have been programming for almost 30 years, mining about a year now and have to admit that trying to figure out the nitty gritty of bitcoin is still a lot of wizard of oz to me.  I have read pretty much every post on this forum for the year and written minergain to log all kinds of details and provide some info (mostly for my mining enjoyment but free to anyone), so I probably have a little more experience basis that many - but there is still a lot of trust involved for my mining.  Fortunately Kano frequently (and personally) shares his knowledge, experience and occasional missteps - and makes me wonder if he sleeps - which does make me very confident we are all being watched over - which Kano obviously believes in long term success versus the quick payoff.  I have no idea how I would even begin to figure out how to "calculate" any intended or unintended issues.  I suspect many of the pool owners are in a similar situation which again makes me happy to be with someone who knows the ins and outs of this...

I have been helping my neighbor with exactly that.  He has 13 miners running on a verizon unlimited.  Not sure unlimited is important since miners do not use all that much bandwidth.  He only has about 2 bars and I actually do not know his ping times, but he is mining consistently.  The hot spot does drop off once in a while (every few days) so I built up a system that resides inside of his firewall.  The system logs in to each miner each minute and if it is below 70% hash rate (can be overriden if a board is bad), it reboots the miner.  I am also putting in a Digital Loggers Web Power Switch that has built in ping ability.  I have the verizon box, the network switch, pfsense router and miner monitoring system on this device.  The first two power cycle if the 2 minute ping to 8.8.8.8 fails twice.  The other devices power cycle if they do not ping directly.

Obviously having more bars is better for ping times and if you ever travel, it is best to have some sort of reboot system in place (Edit - even if it is your neighbor!).

oops, I just re-read and a cell hotspot is not a wifi hotspot is it!  Oh well, the power switch still may be helpful to some here.  Mine On!

Nice to have another green block!  And it was a decent size as of late too with 13.44613634. Thanks Cryptostar! 

Has anyone had luck copying the windows wallet over to the linux version?  I went through the process on my centos box (likely will rebuild it do ubuntu now since it is a vps), copied everything over which took almost an hour vps to vps.  When I started bitcoind, it blew everything away and created an empty wallet..  Any advice to have it go quicker?

**Edit - I am using ssh and a non graphical system btw

Here is a site with several links that I found for centos 7 (what I am building up now):
https://bitcoin.stackexchange.com/questions/43123/how-does-one-install-bitcoin-core-on-a-centos-server
Dont forget to harden your firewall from the outside world.

I have been using bitcoin core on windows for most of a year.  I guess it is time for me to migrate that to linux.  That said, having the full block chain on your own computer helps prevent hacking as well as the health of bitcoin since you are another copy for the system to compare off.  The main reason for not using windows is all the viruses that can intercept what goes between your hands and the internet (Kano, can you confirm).  Keep your firewalls, virus scanners and other security measures in place (including safe browsing and not opening unknown emails) and it will help for the short term.  When you can swing the money and time, probably best to migrate it to linux (which I will be doing now too).

Not if it is consolidated into a single transaction.  It can be a million BTC or 100 satoshis and it is still based on the number of transactions.  If you transfer .00001 BTC that is made up of 4 transactions, it would cost 4 times the fee of a million BTC with one transaction.  It is totally strange how it works - and that is why it is important to consolidate when the fees are low (and you do not care if it takes a few weeks to get merged together into one transaction).  There is nothing worse than having the market go crazy and needing to pay for something with more transaction fees than what you are trying to send due to lots of small mining transactions... 

According to my minergain account with a single S9, based on the prices that the block was found, I made $114 which currently is worth $97 since I am HODL.  My power is .124 per kw, so just under $140 to power it for the month.  So yes, a bit of a loss.  The crazy part is that I just bought and installed 2 more S9's for way less then my first S9 since there are so many coupons going around from bm and they delivered it in a little over a week.  I have bought btc straight out and had more of a loss on that so far.  So it really is whether you believe in the long term opportunity of BTC and whether you can pay for your power and HODL.

Minergain could do a lot more too - including an eventual api - but I have been lazy!  I am happy to help anywhere you like.  Not a problem if you want to continue your processing but if you want me to "auto" hook into your system one way or another, I am happy to help with that too (no charge of course).

That is a great idea.  I am assuming you have a program to feed it in, but if not and you want minergain to auto-fill the found blocks for you, I suspect that would be easy to do.  Otherwise everyone can setup their email or phone to get an alert directly as well.

When you send a transaction to somewhere else, you decide what transaction fee to add to it.  In the case of the exchanges, they make it simpler by picking the highest value (quickest confirm time) for you.  If you want your money moved quickly, you need to put a higher fee so that the miners pick it up right away.  If there are a lot of transactions waiting, that transaction money keeps getting higher to get over the top of everyone else.  As we mine, Kano's software picks out the best transactions for us to use in our mining.  Once we get the block, all the transaction fees get added to our mining proceeds.  So the net effect is that when bitcoin is active (more marketing hype perhaps), we get paid a lot more per block we find.

I always do pretty close to the minimum and check the box to change the fee later on.  A few months ago when it was so crazy, it would sometimes take 3 to 4 weeks but eventually would go through.  You can check minergain at https://minergain.com/faq.html#btctxfees and look at the 1 week amount.  According to the last stats, the mempool is still low at 3.6 Mb, so should still confirm pretty quickly.

Kano, since you are so great with numbers, did you happen to run your own numbers to compare with what minergain has?  I have offered many times to have anyone review the data for accuracy (with no takers), so just curious if you came up with similar numbers or are interested in seeing the raw data?

As others may or not know, I started with slush but am exclusively with Kano due to the rewards but even more because of the amazing support and fellow miners.

Now that I rebuilt the blocks (be aware that I have not fixed the bug for new blocks yet), here are the final totals for April (which matches what ZorzyZii stated for Slush's April count).

Kano - 22 blocks, average 134.35Th/s, 0.0280175 payout for 13.5Th/s
Slush - 496 blocks, average 3.12Ph/s, 0.0273638 payout for 13.5Th/s

My personal payout for roughly 13.58 Th/s from Kano was 0.0278895, so these numbers are close (there are all kinds of rounding differences since pool reporting is done in Th/s, etc).

Here are the CDT values (Coins per Day per Th/s) that also show Kano over Slush short and long term.
Name   Week CDT      Month CDT      Quarter CDT   Year CDT
KanoPool   0.00010197   0.00006459   0.00008834   0.00021177
SlushPool   0.00005526   0.00005896   0.00006884   0.00020906

Thank you for looking into this but please don't put too much stock in this report yet.  As I mentioned, I believe I still have some funky business going on with the blocks.  The pool stats such as shares, users, etc are being gathered each minute (for slush and kano) while the block is being processed.  Once the block is found, the "in process" block is supposed to be replaced with the block number found by the pool. For some reason with my coding for Slush, there were a lot of these "in process" blocks that got updated to the found block plus 1.  When the public block gathering code came along, the found block number was not in the system so it added another record for that block.  As I said, I will look into this more next week since I have several issues for my digital signage paying customer base that I have to take care of this week.

*Edit - if you want to actually count the blocks, you can find them at https://slushpool.com/stats/blocks/.  I just purged the entire block table for slush and am reprocessing them again.

I really think that something is majorly wrong with the new btcstats report I created.  Unfortunately I dont have time to look at it in detail this week but I will check it over thoroughly next week.  Even after rescanning the block information, the home page CDT values (Coin per Day per Th) are showing Kano quite a bit more than Slush, and my experience is that those values are more correct.  I started comparing the Kano values with my own payments, and it is pretty close.  If someone has actual slush reward values (I guess I should check to see if anyone has added their API to the MinerGain reward table), we can compare those actual values to what is reported in this new system.

*Edit - I checked and we have a couple miners with rewards captured from Slush that I will review.  It looks like pool_id 31 (tungting) is the best to review since they have 2068 reward records since 1/18.

*Edit 2 - I quickly scanned this miner's rewards and the block counts in this new report are off by at least one per day. When I rescanned, I did not remove the old ones first which I apparently need to do.  I will purge them all and have the system grab them again from Dec 1.

I finally rescanned the slush and kano records to hopefully correct my issue, so the https://www.minergain.com/?btcstats gives real-time information between kano and slush since last month.  As mentioned, this does not take ramp up / down into account for either pool, but gives you a "what if" of the historical results.  For some reason the CDT values from the home page do not correspond to the values this report, so I may have a little more review to do.  If anyone spends the time to compare, please let me know your results.

that decryption is a great summary, but in the interest of accuracy, it is not really about blocks found, but something to do with your share contribution  percentage for the last 5 times the difficulty worth of shares. Very confusing, and if you prefer to think of it as blocks, whatever helps you understand.

stratum+tcp://nya.kano.is:3333 is also dead (as well as the above) so I am mining to my third option now.

So this turned out to be a bigger project than I figured - plus it exposed a few issues I still have to fix.  In any case, the new miner performance system is up there if you want to start linking to it.  The url for Kano is https://www.minergain.com/?btcstats&kano.  That will bring up a single S9 at 13.5Th/s showing daily blocks for this and last month.  I set it up so that you can also select other pools that minergain tracks, change the grouping to weekly or monthly and enter your own hash rate.  If you have a free minergain account, changes to these values will be stored.

I discovered that I am having issues with the pool hash rate (which is how these numbers are calculated).  For Kano, I am using my calculated hash rate based on shares submitted - and it should be getting updated with the real number when a reward page is updated.  Until I fix this, the reported numbers are slightly lower than the actual reward payouts we receive.  For Slush, I discovered that the pool hash rate is not always getting updated due to a timing issue.  There are 218 of empty pool hash records since December 2017.  I will fix the issue and rescan the history off of slush in the coming days.  There were 2740 Slush blocks during this time, so fixing this will increase many of the Slush CDT value by roughly 8%.

These tables are pretty small to keep it simple.  Please let me know your thoughts on this and thanks again for your previous feedback!