Overview BTC Solo pools

[willi9974]

Hello all,

last 20h someone rented around 460 PHs or more for 10-20h. Knows someone if the hashpower on one BTC solo pool are rised extremly in this time and can wie list all known solo pools here? This will happend sometime and i would be interestet, if this rental hit a block on a other solo pool.

Best regards,
Willi

[jack3rror]

I can assure you they need to mine on Soloblocks.io soloblocks.io

It is profitable (highly).

I finished building it and we have already 2 phs.

[NotFuzzyWarm]

I finished building it and we have already 2 phs.

The total hash rate of a solo pool is irrelevant because only 1 physical miner gets the block and only the 1 owner of that hardware gets the rewards. It might be a Compac Ferrari running 360GHs or it could be a 93THs Avalon. Hash ran by others in the pool does not mean anything to the results.

[Sledge0001]

Don't roast me for this but I think the real question is...

Does the higher amount of hashpower a pool has increase the chances of someone in the pool finding a block (solo or otherwise)?

My thoughts would say yes.

The total hash rate of a solo pool is irrelevant because only 1 physical miner gets the block and only the 1 owner of that hardware gets the rewards. It might be a Compac Ferrari running 360GHs or it could be a 93THs Avalon. Hash ran by others in the pool does not mean anything to the results.

[jack3rror]

I finished building it and we have already 2 phs.

The total hash rate of a solo pool is irrelevant because only 1 physical miner gets the block and only the 1 owner of that hardware gets the rewards. It might be a Compac Ferrari running 360GHs or it could be a 93THs Avalon. Hash ran by others in the pool does not mean anything to the results.

Total hashrate on a solo pool is relevant in case you need to know if mining pool is highly available and highly resiliient or just a piece of crap nodejs code on a VPS server.

Does the higher amount of hashpower a pool has increase the chances of someone in the pool finding a block (solo or otherwise)?

My thoughts would say yes.

Amount of hashpower increases your ability to find a block quickly but doesn't affect Luck.

 

[mikeywith]

Does the higher amount of hashpower a pool has increase the chances of someone in the pool finding a block (solo or otherwise)?

It increases the overall chances of "the pool" finding a block, the only person who gets those added chances would be the one who added that hashrate, the rest of the miners' chances will not be affected by this.

Think about a hunting trip where 1000 people randomly shoot at the woods' side hoping to catch some deers, those people join forces in teams, let's say 100 hunters in each team, now imagine they all shoot at the same rate, now someone "John" in team B decides to buy a gun with a higher fire rate, team B's chances to hunt a deer will now increase, in fact, the chances of the whole hunting group (1000 hunters) increase, but just because "John" now has more chances of hunting a deer than he did before, it means exactly nothing to "Bruce" who is also in team B.

Now that is the solo mining part of it, with pool mining (hunters in the above example share the deers which anyone of them hunts based on the number of bullets each of them shot) it helps smooth the rate at which the hunters get to eat some meat, which is why mining on a large pool gives you a sort of frequent small rewards while small pools give you larger chunks at larger intervals, eventually when measuring against infinity they all give you the same rewards provided that your hashrate has not changed.

That's pretty much how mining works, I can't think of a simpler way to describe it, but if you still have any questions, feel free to ask.

[Sledge0001]

I think that your example clarifies it to some extent.

The more hashpower a solo pool has the better odds are that the pool will find a block.

The solo miners hashpower in that solo pool still has the same odds as their contributed hashpower to said pool.

Is that a correct deduction?

TIA

It increases the overall chances of "the pool" finding a block, the only person who gets those added chances would be the one who added that hashrate, the rest of the miners' chances will not be affected by this.

Think about a hunting trip where 1000 people randomly shoot at the woods' side hoping to catch some deers, those people join forces in teams, let's say 100 hunters in each team, now imagine they all shoot at the same rate, now someone "John" in team B decides to buy a gun with a higher fire rate, team B's chances to hunt a deer will now increase, in fact, the chances of the whole hunting group (1000 hunters) increase, but just because "John" now has more chances of hunting a deer than he did before, it means exactly nothing to "Bruce" who is also in team B.

Now that is the solo mining part of it, with pool mining (hunters in the above example share the deers which anyone of them hunts based on the number of bullets each of them shot) it helps smooth the rate at which the hunters get to eat some meat, which is why mining on a large pool gives you a sort of frequent small rewards while small pools give you larger chunks at larger intervals, eventually when measuring against infinity they all give you the same rewards provided that your hashrate has not changed.

That's pretty much how mining works, I can't think of a simpler way to describe it, but if you still have any questions, feel free to ask.

[mikeywith]

The solo miners hashpower in that solo pool still has the same odds as their contributed hashpower to said pool.

The solo miners who did not add more hash power still have the same odds, only the odds of the person that added more hashrate will increase and thus it increases the odds of the pool as a whole.

The more hashpower a solo pool has the better odds are that the pool will find a block.

That's correct.

[nullama]

Don't roast me for this but I think the real question is...

Does the higher amount of hashpower a pool has increase the chances of someone in the pool finding a block (solo or otherwise)?

My thoughts would say yes.
~snip~

In terms of probability in doesn't matter for each individual miner, it only matters how much hashrate they provide individually.

What I think is significant is that if you have a pool with a high enough hashrate that means that there will be blocks found, and therefore fees will be paid to the pool, which will allow the payment for the servers and so on so the operation can continue smoothly for everyone.

But if you have a pool with low hashrate then probably no blocks will be found, server bills will arrive and with no incoming blocks the pool operator might have to shut the operation down.

[Sledge0001]

In terms of probability in doesn't matter for each individual miner, it only matters how much hashrate they provide individually.

What I think is significant is that if you have a pool with a high enough hashrate that means that there will be blocks found, and therefore fees will be paid to the pool, which will allow the payment for the servers and so on so the operation can continue smoothly for everyone.

But if you have a pool with low hashrate then probably no blocks will be found, server bills will arrive and with no incoming blocks the pool operator might have to shut the operation down.

It still comes down to me trying to grasp this.

When a pool gets a job that job is then distributed to the miners that are connected to the pool.

So in my mind it would stand to reason then the more hashpower a pool has the better off or luckier a miner would potentially be at hitting a block if they were to be mining there. Solo or otherwise.

I just don't see how that wouldn't be the case.

[philipma1957]

In terms of probability in doesn't matter for each individual miner, it only matters how much hashrate they provide individually.

What I think is significant is that if you have a pool with a high enough hashrate that means that there will be blocks found, and therefore fees will be paid to the pool, which will allow the payment for the servers and so on so the operation can continue smoothly for everyone.

But if you have a pool with low hashrate then probably no blocks will be found, server bills will arrive and with no incoming blocks the pool operator might have to shut the operation down.

It still comes down to me trying to grasp this.

When a pool gets a job that job is then distributed to the miners that are connected to the pool.

So in my mind it would stand to reason then the more hashpower a pool has the better off or luckier a miner would potentially be at hitting a block if they were to be mining there. Solo or otherwise.

I just don't see how that wouldn't be the case.

nope

you have one shovel trying to mine a share higher than 29trill

I have five shovels trying to mine a share higher than 29trill

I am five time more likely to hit than you and In the current difficulty period of 29 trill nothing I do with my gear helps or hurts you.

However
it the longer run if I do enough shovels to raise the difficulty to 30 trillion or higher for the next adjustment.

than you have a smaller shot to hit the block.

[Sledge0001]

nope

you have one shovel trying to mine a share higher than 29trill

I have five shovels trying to mine a share higher than 29trill

I am five time more likely to hit than you and In the current difficulty period of 29 trill nothing I do with my gear helps or hurts you.

However
it the longer run if I do enough shovels to raise the difficulty to 30 trillion or higher for the next adjustment.

than you have a smaller shot to hit the block.

I understand the odds go up the more miners you have (shovels in your analogy) and the odds go down as the difficulty goes up.

But if a pool distributes the jobs randomly then I just don't see how the pools combined hashpower wouldn't effect the potential of the miners involved solo or otherwise.

Maybe I am not grasping how the pool gets the job from the network as well as I should.

Any additional information on this process would be appreciated.

[mikeywith]

When a pool gets a job that job is then distributed to the miners that are connected to the pool.

So in my mind it would stand to reason then the more hashpower a pool has the better off or luckier a miner would potentially be at hitting a block if they were to be mining there. Solo or otherwise.

I just don't see how that wouldn't be the case.

The pool doesn't get a job from the network, the pool creates jobs for its miners, I think I understand where the confusion comes from, you need to understand how mining actually works, and to do so, let's just forget about pools, and pretend that there are just 10 miners mining bitcoin, so Satoshi mined the first block with a difficulty of 1 (does not matter how he did it) and now the 10 miners are trying to mine the second block.

The first block has a "block hash" and let's just pretend it's "2222" in this case, now every miner will take that number 2222, add a random number to it, then hash it into the sha256 function to hopefully produce a "hash" that has a certain amount of zeros in front which is the "difficulty", now for the sake of simplicity we will pretend the current difficulty is 1, or in other words, the hash needs to have 1 single zero in front to be taken as a successful block.

So now I take that hash of 2222 and put it into the hash function it gives me

Code:

edee29f882543b956620b26d0ee0e7e950399b1c4222f5de05e06425b4c995e9

Any leading zeros? nop, ok then I need a random number to it, and that random number is called NONCE.

let me try to add 1 after 2222, so I hash 22221

it gives me

Code:

59dad30654dd2ea8f8b27ef495a801969db3df45c2c27eaa7cdecbc6792b6ba8

no luck, let me add 2 after 2222 and hash 22222

it gives me

Code:

cc399d73903f06ee694032ab0538f05634ff7e1ce5e8e50ac330a871484f34cf

note: those hashes are real hashes, taking 2222 and adding all the numbers from 1 to 57 did not give me a zero, but then the number/nonce 58 gave me that, so if you hash 222258 you get this hash

Code:

0789d652274665285d3a581e584c2114790d335dbc95f107bfaf4b7c10de524d

You can confirm this or do a similar practice using this website > https://emn178.github.io/online-tools/sha256.html


So now when I hit this, I will broadcast to the network, and tell them, hey I found a block, it's hash is

Code:

0789d652274665285d3a581e584c2114790d335dbc95f107bfaf4b7c10de524d

The nonce I used was 58

everyone knows the previous block's hash was 2222, so they will hash 222258, if it really does start with 0, they will accept the block, and then use the new found hash to try and get another hash that starts with 0, until the difficulty changes and then they need to find a hash that starts with 00 or 000.

I think now everything about the basic mining process is clear right?

now imagine every one of these 10 people became a mining pool and has thousands of miners mining with him, it doesn't make any sense for everyone to start adding 1 and then 2 and then 3 to get to that 58 number which solved the block, everyone will be doing the same work, redoing the work the someone else did is pretty useless, as a pool operator I want the miners to try a different set of nonce/random number

I want to tell miner A, to start trying from 1 to 1000 , miner B to start from 1001 to 2000 and so on and so forth, but then I don't know if miner A will finish his 1000 tries in 1 second, it will also take a lot of recourses to allocated certain limits to every miner so what I do is, I don't send them the same work/hash

I send miner A 2222A I send miner B 2222B, this way I know even if they both start hashing 1,2,3,4 their results will be different and no duplicate work will happen.

So now, if miner B buys a large farm and I send him 2222B the total number of "digits" he can hash is limited, let's say it's only 5 digits so  2222B-----, he will do 2222B10000 and then 2222B10002, very soon he will reach to 2222B99999 and he has no more digits to change, the miner in this situation will need to change one of the parameters to open a new door of possibilities, so maybe he will do  2222BB----.

Miner B now has more chances than before because he can try more hashes, which means the pool as a whole has more chances, but miner A's chances are still limited.

The short version of this whole thing is that every individual miner has his own "job", in fact, every hash board of your miner or even every chip has its own work/job, mining to a pool does not change that, mining to a pool is like mining solo but with a promise/obligation to pay the other miners a % based on their hashrate contribution, and are also are under the same obligation, in the end, it's only 1 miner that finds the block, the pool system simply devices the profit between all miners based the hashrate.

In a solo pool like CK, the pool gives all the profit - fees only to the mine which found the block.

Please note:

** Changing a single digit in the input of the hash will give you a completely different hash, so hashing 2222B0000 will not be the same as 2222b0000
** Not only 58 solves the 2222 block, but there are dozen of other numbers that do so, it's all random, for an example 22221234 also has a hash with 0
** Miner B has more hashrate and can try more numbers in the same period of time compared to miner A, but that does not mean miner A can't beat him to the race, it's just that based on probability miner B is more likely to find a good hash

Finally, please keep in mind the above explanation of how the pool specifies different jobs to miners or how miners submit a block or what value do they hash and how they hash it, is an extreme oversimplification of the real process, there are many more parameters involved but by the understanding the above you will at least haveve a good clue and clear some (if not all ) of the confusion.

[kano]

Simplest answer is that all miners mine different work no matter where they mine.

If you have 2 people with the same hash rate, solo mining on the same pool or solo mining on 2 different pools, it doesn't matter, they must each have different work either way.
Their expected results is purely based on each their own hash rate and has nothing at all to do with the pool (unless the pool is throwing away blocks like ckpool solo does by giving you stale work that will not be rewarded if it finds a block)

If the 2 miners didn't have different work, then they would be mining the same answers and would expect to find exactly the same blocks, thus total expected blocks would be the equivalent of half the total hash rate.

Every block found on the block chain is obviously different.
If 2 different miners, with different work, find a block at the same height, even those 2 blocks will certainly be different, and only one of the two will end up in the block chain.

Of course there's Help pages on my web site with details about mining.

[Sledge0001]

@mikeywith and @Kano

Thank you for this. It does clarify things a bit further on how jobs are created at the pool level.

[jack1cryptotalk007]

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.

[mikeywith]

.
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.

I believe the pool's bitcoin address must be hashed into every share the miner submits, the pool won't add it later, the pool will simply relay the block as is. Correct me if I am wrong.

[a1 Hashrate LLC2022]

In terms of probability in doesn't matter for each individual miner, it only matters how much hashrate they provide individually.

What I think is significant is that if you have a pool with a high enough hashrate that means that there will be blocks found, and therefore fees will be paid to the pool, which will allow the payment for the servers and so on so the operation can continue smoothly for everyone.

But if you have a pool with low hashrate then probably no blocks will be found, server bills will arrive and with no incoming blocks the pool operator might have to shut the operation down.

It still comes down to me trying to grasp this.

When a pool gets a job that job is then distributed to the miners that are connected to the pool.

So in my mind it would stand to reason then the more hashpower a pool has the better off or luckier a miner would potentially be at hitting a block if they were to be mining there. Solo or otherwise.

I just don't see how that wouldn't be the case.

it is very simple math.

1eh should earn

1000000 x 0.00000421 btc in a day that is 4.21 coins a day

1,484,560 th x 0.00000421 btc = 6.25 coins in a day


so 1,484 ph should earn 1 block a day with avg luck.  no more. complex than that for this diff jump.

this means use 1,484,560 th and then if you have an s17 use 50 th

1,484,560/50 = 29,691 to 1 per the whole day for an s17 at the current diff.

an s9

1,484,560/14 = 106,040 to 1 per the whole day for a s9 at the current diff

[jack1cryptotalk007]

.
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.

I believe the pool's bitcoin address must be hashed into every share the miner submits, the pool won't add it later, the pool will simply relay the block as is. Correct me if I am wrong.

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.

[mikeywith]

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.

I think that is incorrect, if that was the case, i could just mine to a pool, submit shares, get paid, but once i find a block i just put my own address as the coinbase address, which of course can not be done.

The nonce you are hashing is done against many things, one of them is the coinbase transaction which must be in the block header, that transaction ensures the payout goes to the pool address, if you change anything in that transaction the hash you sumbit will be invalid to both the pool and the network as a whole.