Hash Rate versus Internet Usage

[gt.townsend]

I have over 30 GPUs mining various coins, a half dozen Sia coin ASIC miners, another half dozen Dash ASIC's, some BTC ASICs and more than just that. Lets consider ONLY my BTC miners. There are only three ASICs running which together average about 35TH/s. Ignoring all my other equipment, I can't make heads or tails out of my internet usage, which averages about 300GB/month.

Something just doesn't add up.  35 TH/s is 35,000,000,000,000 hashes per second. Multiply that by 3600 seconds in an hour, 24 hours in a day and 30 days in a month, that's 90,720,000,000,000,000,000 hashes per month. Even if each hash only required a single byte to be exchanged in each direction between the miner and the mining pool, this would require 600 million times more internet bandwidth than I am using.

So what exactly is a hash? I thought (apparently naively) that the pool sends you a big 256 bit number and you "hash" it by XORing its bits with a key and with rotated versions of portions of itself, generate a new number and send it back to the pool, and if your miners are generating 35TH/s, then this happens 35 trillion times per second. I guess that's obviously not what's happening.

Just to put my question in context, I'm a computer science professor, but obviously not an expert in this field, however I have had several of my students under my direction implement portions of cryptonightV8 on an FPGA and checked the sub-results against the mining software. I have also developed a complete Keccak implementation on an FPGA for mining Smartcash and I dissected cpuminer to check my hash from my FPGA solution against the hash produced by the software. Right now I'm trying to understand the front-end aspects of mining so I can implement the entire protocol on my FPGA (my FPGA contains a CPU which is C programmable, so I can think more abstractly for some of the front-end tasks, and leave the low-level FPGA stuff for the actual hashing - which is complete). In other words, I think I know what hashing is. However, I can't reconcile the ratings of the miners against the bandwidth of my connection.

So, I need some help understanding what 35 TH/s really means, how it is calculated, and how to relate this to the amount of information exchanged between the miner and the pool. Can anyone help?
-gt-

[1715186626]

1715186626

[1715186626]

1715186626

[1715186626]

1715186626

[1715186626]

1715186626

[1715186626]

1715186626

[1715186626]

1715186626

[ranochigo]

When you are mining with a pool, the pool provides the miners with the block header that the pool has determined. This includes the merkle root (hash of all transactions), its coinbase and an array of other information. The miner can then assemble this to form the block header that the miner has to hash. The block header is hashed twice and checked if it meets the difficulty requirement. The miner changes a variable in the block header every time it hashes it once (timestamp or nonce etc). Doing so results in the miner generating a different hash and this happens for million/trillion times a second without the server sending any more information.

The pool does not have to continuously provide the miner with a new block header as the block data is valid for sometime before it has to be changed. Information is only sent to the server if the miner has a hash that meets the minimum difficulty that is set by the user/pool.

[gt.townsend]

Perfect! That was an excellent (and concise) explanation. Thanks so much for that. That's the missing link that I didn't understand. You see, I had it in my mind that I could just do the hash function on the FPGA in a black box and have my miners handle the front end and communicate with it to do the actual hashing, but even within my house at a local level it became clear that the bottleneck was going to be communication with that black box. In the case of the "partial" hash function that my students implemented for Monero, we even had what we called a "hash server" set up with a number of computers doing a remote procedure call to it (with concurrency issues cleverly handled) and it was mining live on an XMR pool successfully. It was all just a "proof of concept" experiment, but it worked and it mined! However, when I started doing the math I realized that although 24 rounds of Keccak was executing thousands of times faster in the FPGA than in the software,  since I was doing a single hash at a time, it was taking way too long to get the data to and from the FPGA "hash server" to the local miners in the house.

So if I understand what you told me, I need to also implement this "merkel tree" business local to the FPGA so that it can in turn execute millions/billions of hashes iteratively  without having to exchange information with the pool (or with my miners in my case of this "hash server" architecture I described).

Now although I can continue reverse engineering the cpuminer software, it took a tremendous amount of effort to just sort out what I've done so far - to that end, can you point me to some resource that would describe the technical details of dealing with the merkel tree? Since this is a BTC forum, I assume such resources would be for BTC, but since I'm interested in SmartCash/Keccak (my Keccak algorithm in the FPGA is phenomenally fast) I'd prefer either more generic coverage or something specific to Keccak than just BTC only. Do you have any suggestions about where I might find what I'm looking for? Thanks in advance. You've been a great help!

-gt-

[odolvlobo]

The protocol used by Bitcoin mining pools is call the "stratum" protocol. Here is the documentation: https://slushpool.com/help/manual/stratum-protocol