Hashrate = difficulty x time  This is a confused concept, what is diffculty?  

Hashrate is just how many time of hashing can you device calculate (or process or do) on a block header which is a 80 bytes data (or message) during one second time period. In bitcoin, two pass sha256 calculation on a block header data consists of a hashing which produce a hash value for an message.

On CPU miners, it is very simple, how many time can hash function complete calculation on a block header data.
On ASIC miners, it is complex a bit, 1st sha256 is calculated by CPU, then, 2nd hashing (2nd pass sha256) is ran by ASIC chip. Then, output nonce is varified by CPU again. So, there are various formats to calculate hashrate in various softwares, which, I said, are not acuracy or confused.

So, I prefer how many block headers (or local works) can be processed during one second as a benchmark to quant the processing capacity of a hashing device, which can be a good base for comparation of various miner capacity. My cgminer can display how many works has been hashed out on screen.

I found that frequency increase => hashrate increase, sometime, hashed_out works can be varied or not incresed, which means device fail to increase its hashing calculation capacity. And frequency increase often produce more hot and easy to burn out asic chip. So, I only use 300 MHz for BM1397 stick.  

Buying more hardware will increase your hashing capacity. But, it will cost your capital and running cost. Now, bitcoin price drops to $21k USD. Then, mage miners, pools will run under loss, and quit their business. If bitcoin drops to $5k USD, very feasible scenario, running cost will kill a lot of miners.

The pool keeps all necessary data about block header and transactions for a valid submit to bitcoin network and miners are not given all data by the pool. So only the pool can submit solved block header which includes nonce. Transaction data, sometime, is a huge data; so it won't be given to miners in stratum mode. This answers your curious or doubt.

No. miners submit their every share submission don't include the pool's bitcoin address, and these submit are just communication between miners and the pool.
The pool's submit to the bitcoin core (or bitcoin network) must include the pool's bitcoin address, otherwise, you won't get bitcoin rewards. The data submit include: block header data (hex big endian byte order) + variant data + coinbase data (contains a pubkey of pool's bitcoin public address) + tranaction varified data + transaction data.

The bitcoin core (bitcoin network) will calculate hash from the nonce with block header data. The bitcoin network does not deal with pool share issue, operation, etc.

1. A pool got transaction data from bitcoin core network.  
2. Then, pool pass block header data to miners (solo miners or pool miners). the pool also use job_id, ntime with every header data.
3. Miners use block header data to create a lot of local block header data (or local works) by using different nonce2 (64 bits).
4. Then, local block header (or called local works) are hashed by miners' bitcoin mining machine.
5. If a nonce is found, job_id, ntime, vmask, nonce2, nonce, and user_id are sent back to the pool. Then, the pool re-create block header data, and test it.
6. Then, the pool submit validated block header data with the pool's a bitcoin address to bitcoin core network.
7. Then, new found block header data must be confirmed by other nodes in bitcoin core network. New block header is recorded in block header tree in bitoin core network.
8. Then, reward can be created, and can be given to the pool.
9. Then, the pool pass some reward to the miner.

This is a flow of all processing. Any error would occur during this flow.

My personal opinion, a miner need to use a different starting nonce2 for every new block header data in order to avoid the collision of hashing the same header data with each others. eg. slow miners may hash the same header data which has been hashed out by fast miners. This is a drawback which you can fix by yourself.  There is no other issue in stratum pool mining if the pool will not got wrong in their servers and their database.

does S19 use cgminer?
what is computer in S19?

I take an example for you to know difficulty and target in bitcoin network
Today, the block with bloch height: 726543, was found by F2Pool  pool.
F2Pool got a hash value: 0000000000000000000a0e711d57f1a3916ba51df413256f15f220bdb9f22ed8,   19 x '0',  a0e711....
For this hash value, a difficulty can be calculated by a formula,  difficulty is 27.99 T.
Now, bitcoin network set a current network difficulty is 27.55 T.  Once 27.99T > 27.55T,  then,  F2Pool found the block, got $$$$$$.
27.55T  is about  27, 550, 000, 000, 000.   

In cgminer,  when a hash is hashed out by asic chip, it calculates a difficulty with the hash value. Then, compare it with past maximum
difficulty value. Then, record a new maximum difficulty value as the best difficulty or call Best Share difficulty.

Best Share (difficulty) is the best hash value you mining machine has achieved or worked out so far in this run.

In bitcoin mining, an extreme small hash value is sought for a block header data.  Hash value will be from 0000....00 (64 x '0')  to ffff...ff (64 x 'f'). Which is a space M for sha256 algorithm space. This space M can be divided into a lot of small space n1, n2, n3, ......nm.  So,  smaller than 19 x'0'  hash values is a specific space for bitcoin.  So, this specific space is a target space (space T). Smaller than 19x'0' hash value is  called target.

I don't know what is distribution of sha256 output hash value.  But, normal disribution is bell sharp, medium section got more chance to come out, extreme chance on both extreme end. More extreme smaller space, more difficulty hash value will fall in this space.

Hi, ck hero,

Please allow me to ask you a question?

In your solo pool, there may be some extreme fast solo miner running in front of pool with new block header, can it cause slow miners to run on the same local work (block headers generated locally in cgminer) which have already been hashed out by those fast miners?

Is the coinbase data the same for all solo miners in your pool?

Great Thank You for sharing your great experience with us!  Wonderful!

Hi,  you got 17 PH/s huge miner. May I ask you if you can solve one block header every day? 
I just like to know on statistics purpose.

miner program (eg. cgminer) have a longpoll_thread which is keeping polling to full-node (eg. bitcoin core) in a speific seocnds. When a new block come out, height of block header is different, then, miner program go to get new block header's data to form a new block header to be hashed out.

I only buy on eBay or Amazon.  They can handle complaint and take money back from seller's account or chase money back.

To be blunt, it isn't an important change either, since it gives most people the completely wrong impression that solo mining to your own wallet is a good idea.
It's not. It's a BAD idea.
Solo mining to your own wallet has a MUCH higher risk of losing a block.

I agree the above opinnion.

I print out some details of transactions in block headers from bitcoin core. I found bitcoin core has an major problems that it sometime provide fewer transactions (eg. 10 transactions) included in getblocktemplete return message. So, the block headers from the bitcoin core may be wrong sometime, I believe. But, solo miners couldn't do anything with bitcoin core in regarding the numbers of transactions included. This is a key issue for bitcoin core to be used for small solo miner independent mining action.

I believe that bitcoin core with cgminer in gbt_solo mode, solo miners will get a big risk in reliability issue of block headers. eg. your block header got only 10 trans, others got 300 trans.  This may be a problem for equal opportunity right in bitcoin network???

The bitcoin core may be usable for running your own wallet without realtime reliability issue. But, it is not purpose for yourself solo miner's mining.

I heard some pools can get all transactions packed and just wait for previous block hash coming in. Then, their block headers is formed. Much quick. Or if a pool resolved a block, and delay submit, and form a new block, and hashing it out. So, a block is resolved in few seconds from the same pools which often been seen. It is rare chance to resolve a block with a nonce. But, it is even hard to find second nonce for the same block. So, often, saw a block would not be solved for longer time, then, suddenly, few blocks are solved in next few minutes. It is funny thing in bitcoin mining. Or corruption? Or equal opportunity right? Only USA government can address these issue?

1. check voltage pf power, etc. if power is not work, chip will not work. This is major cause.
2. check usb port on unit or on your pc. if usb is not work, __usb_init() will not find chip.
3. check if green light on the stick is on. no light, usb stick is damaged.
4. plug out 5 usb sticks, only left one usb stick, check which usb stick is wrong.
5. remove cgminer, then, re-install cgminer. when code got damaged.
6. run debugging to trace error, check total_devices?  check __usb_init()  function.
7. the 0-rules must written into linux. Read README.

Thank you for your reply!
1) Can you share the link of your post?

https://bitcointalk.org/index.php?topic=5367074.0

2) Also, can you tell me where specifically I can setup start nonce in CPU miner program(any)? Correct me if I am wrong, I need to clone the miner program from Git and after making my changes in the algo, build it?

cpuminer programs: 
1. these are old software, you have to spend time to let these programs run (rebuild).

https://github.com/cryptozoidberg/cpuminer-multi/

https://github.com/pooler/cpuminer.git

or google "cgminer + cpuminer"

2. or you can modify cgminer back into cpu mode. The kanoi version of cgminer

https://github.com/kanoi/cgminer


Work hard, Good luck.

In CPU miner program, you can setup nonce from 10k start to hash out a block header data. But,

In ASIC miner program, the chip is setup to search any nonces which produce a small hash value. the chip automatically brute force try nonces in all range of 0x00 to 0xffffffff. And asic chip is working extreme fast, 10k times trials cost no much time.  eg. my asic miner, 25 minutes period, hash out 13,000 block headers (work), produce 6965 nonces which produce small hash values, start  00000000. (pass 1st test).

I understand your idea about algorithems. But, now, asic chip is widely used in mining device. the nonce is not issue for successful in mining bitcoin. It is a better (or optimalized) block header (work) which may enhance your chance to solve a bitcoin. Your algorithms should focus on how to get better block headers (works) to reduce your workloads against big pools or avoid to repeat hashing the same block headers which has been hashed out by fast miners in your pool.

Other ways is to build a 1PH/s + hashrate miner. see my other post.

Thank kano,

Now, I got much understand about hashrate in various views, eg, as you guys pointed out:
a found nonce's hash value --> share difficulty or work difficulty, then, sum up difficulty*4.29G for hashrate.

But, some hash value is a bit good or bit bad which can produce different difficulty value.
This is a quality measure of found hash value from nonce, which is not subjected to asic chip, or
device processing speed capacity.

My benchmark using number of processed works in second as a quant measure of processing works
capacity and speed, is correct in logic, I believe. So, I can estimate how many works may include a work which
may produce an extreme small hash value for resolving a btc. I use practice data.

Every day, we got 144 btc in bitcoin network control measure, or 144 x 10 minutes. Three miners are studied:
Every day for 21.5 GH/s miner can process (or hash out) works: 144x3000            =>  432,000 works.
Every day for      1 TH/s miner can process (or hash out) works: 144x139,800       =>  20,131,200 works.
Every day for      1 PH/s miner can process (or hash out) works: 144x139,697,400 =>  20,116,425,600 works.

Foundy USA data is used. She got huge process work capacity. She can often resolve a block in 1 minute.
1 minute,   she can process 405,010,702,080 works  
2 minutes,  she can process 810,021,404,160 works
5 minutes,  she can process 2,025,053,510,400 works
10 minutes,she can process 4,050,107,020,800 works

How long can three type of miners process 405,010,702,800 works as an minimum quant of hashing work capacity to hit a btc?
21.5GH/s miner, 405,010,702,080 works / 432,000 works            => 937,524 days / 365 days => 2,569 years. yek! 2569 years need.
1TH/s miner,      405,010,702,080 works / 20,131,200 works       => 20,119   days / 365         => 55 years. yek!
1PH/s miner,      405,010,702,080 works / 20,116,425,600 works => 20.1 days.  seem a hope!

So, my conclusion is only 1PH/s miner can survive in this business. Other small miner just waste energy and time, and should not jump in this business. Any other way to do this business?

So, I have to build a 1PH/s+ miner in years ahead for a better business feasibility.

I believe I has answered the quiestion: hashrate, usage of hashrate, luck, share, difficult.

Bitcoin Core v0.21.1  has no problem for solo miner. mining cmd: getblocktemplate and submitblock got no changed and work well.

cgminer 4.11.1 need to fix it to work on gbt_solo mode. The cgminer got three work modes: has_stratum, has_gbt and gbt_solo.
I found it is very hard to run c code when segment faults often pump out. You have to work out yourself as solo users.

In early stage, CPU is used to do hash calculation. Trying 0x1 with the block header by calling sha256 function once. Then, trying 0x2 with the block header by calling sha256 function again. .... Trying 0xffffffff with the block header by calling sha256 function again. Then, this block header has been hashed out(completed). THen, create another block header data which is called local work. Then, do all hash calculation again. ...   until you solve a block header or other guy solve the block header.

Now, asic chip is used in mining machines (or mining devices) as tool to do hash a block header. A block header data is written into (send to) a asic chip (or usb write block header into asci chip data buffer with a command). Then, asic chip process the block header data, and produce few nonces. Then, this work has been hashed out. We count 4.295 GH per work to give to this asic chip or asic device. If a asic chip got 21.5 GH/s speed capacity, then, this asic chip can process 5 works per second. It should sum up 4.295 G once the asic chip complete every task and produce found nonces.  hashes += 0xffffffff in c program (4.295 G sum up). But, some software use different ways to work out their hashrate, eg. sum up 4.295 GH on every test nonces which is output from asic chip. Issue is some work got no nonce ouput or multiple nonces from asic chip completed process of a task(work). Some pool may use different ways to work out pool hashrate.

A pool may got a lot of miners with a lot of mining devices or asic devices or GPU devices, etc...  

Difficulty is another concept.  next talk.

Mining bitcoin, you got block header which consist of 80 bytes message from a pool or from bitcoin core server, etc.

Then, you use nonce 0x1 with this header, and hash this header. this process is one hash.

cycle nonce from 0x1  to 0xffffffff with this header. these process complete a work full hash out.
It needs 4.295 G time hashes to complete brute force search on one block header, or 4.295 GH to hash out a work.

It is unlikely to found an extreme small hash value from hashing a work. So, you produce another block header (called local work) to hash it again. repeat doing this brute force process to search an extreme small hash value from a work.

Hashrate is a speed measurement of hash times done in per second. eg. 4.295 GH/s mean your device can do 4.295 G hashes in 1 second to process a work, eg. use bitcoin network benchmark 10 minutes control measure:
21.5  GH/s  can process or hash out 5 works in per second.           10 minutes, process 3000 works.
1      TH/s  can process or hash out 233 works in per second.        10 minutes, process 139,800 works.
1      PH/s  can process or hash out 232,829 works in per second.  10 minutes, process 139,697,400 works.

It is more chance to found a work which produce an extreme hash value if you can process more works.

All pools, solo miners get block header data are different due to data input time or different transactions contained in block header, they all work on their different block headers, so, no competition between them. You should not be fear of big pool. There may be some competition within the pool if the pool use a single header data for all clients without coordination.

It is a luck if the work you process can produce an extreme hash value. But, it also depend on your miner process capacity. I prefer using how many works can be processed in per second as a benchmark.

Largest pool at moment, Foundry USA got 28992 PH/s process capacity or their mining device can do 28992 Peta times hashes per second.  I saw one header was solved in about 1 minutes by the pool. How many works this pool can  process:
1 minute,   she can process 405,010,702,080 works   or 405   G works
2 minutes,  she can process 810,021,404,160 works   or 810   G works
5 minutes,  she can process 2,025,053,510,400 works or 2,025 G works
10 minutes,she can process 4,050,107,020,800 works or 4,050 G works

But, sometime, it can be not solved in more than 1 hour.
Other pools use different block headers. If your block head is good, you can solve a block before big pools.

getblocktemplate and submitblock cmd in bitcoin core seem not affected by taproot stuff. bitcoin core code has no modified.

---

I wonder if cgminer can work without using midstate in its work->data  with BM1387 or 1389
driver.gekko.c use midstate in init_task(). Has anybody tried before?

If don't use midstate, what is the cmd sent to usb?  now, it is 0x21.  (info->task[0] = 0x21)

In gbt_solo mode, it is better not use midstate. There is a problem in data flip or big endian order byte issue.
It seem different using midstate to meet data from bitcoin core.