Topic: Overview BTC Solo pools (Read 971 times)

Absolutely agree to this point. Anyone can look at the coinbase transactions that a pool has set. When the miner does his work and finds a valid hash below the target, it's all based on the block header that the miner originally received from the pool. If the miner now passes the valid hash to the pool and a malicious pool operator were to try to retroactively modify the coinbase transaction in his favor, then the nonce value would not fit at all. The pool operator in this example cannot therefore subsequently modify the coinbase transaction in order to defraud the miner.

But
What a malicious pool operator could do, however, would be:
The malicious pool operator first configures a valid coinbase TX and let his pool run for months or a year and hoping that many users will check it and make sure it is correct. He tries to attract a lot of users onto his pool. And after he has built up the trust of his users and gained many users he could e.g. after months or years suddenly and unknowingly changing the coinbase TX for the mining afterwards. He enters his own address as the payout address and removes the miners address. The miners would never notice this unless they check the coinbase TX beforehand for each mining process.

An even worse scenario would be if the pool operator periodically made this coinbase change according to set procedures, with the hope that users would not notice it. For example, he could use a good coinbase TX for 12h per day, and a malicious coinbase TX for the remaining 12h per day. Or at other intervals and irregularities with the goal that a user trying to check the coinbase TX of his pool will not notice anything.

But as a remainder: We went totally off-topic.

Kindness is more sexy than telling me via PM I don't understand what I do by not understanding your exact request (in english by the way, sorry that I don't speak well this langage)
I really don't bitch, I tell only what I think about mining and tries to improve it, and what I think about it right now. And tired to see that really nobody gives a f;

It's highly concentrated, nobody verifies jobs, nobody verifies earnings, PPLNS and scoring is shady as F.

Now it's a chance for miners to stop going on shitty highly centralized pools.

It's purely pro bono at 0.4%

Thanks for your constructive message, really appreciate it and will consider every single point.

you should stop spreading lies, you are not making your entry into the pool business any easier. I had answered you by DM


Not sure if understood correctly but keep in mind that most serious solo pool users rent hash power and send lots of hashpower to a solo pool. So I do, I always rent > 1 PH/s for solo mining lottery. There won't be only USB miner on a solo pool.

Don't get me wrong, I think your effort and project is great and competition is always good as it stimulates the market and supply. Of course, it's hard for you as a newcomer to attract new users. If you ask me, you should start where others have failed or continue to fail and do it wrong. Your ultimate goal should be that your pool finds a block and the reward is successfully paid out to the respective miner, in the best case even to a longtime member here in the forum with a good reputation. That would catapult you to the top and you would be in business.

A few suggestions from my side that might help you:

- stop bitching about other pools or people. Leave bashing to others who are good at it and have been doing it forever (e.g. Kano). By deliberately and maliciously badmouthing others, you do not make yourself better. Also the community doesn't care if you're coding in your free time or not, there are far more important things in this bussiness.

- include "bestshare" and "bestever" information into your statistics

- your ports only offer low diff or high diff, but no varDiff or customDiff is possible. For example port 3333 always offers fixed 65536 diff shares. You should fix that and upgrade the feature set accordingly.

- implement more servers spread over all continents (one server is not enough and would be a single point of failure)

- blaming others or slipping into the victim role will not help you, but will have the opposite effect

- add your instructions for checking the coinbase transaction to your website. You've already put a lot of effort into this great guide and you're the first, so that's a big plus for you. Work this out further in detail step-by-step (for command line) so that potential users will be motivated to check it themselves.

- think about how you could advertise with a sponsoring program or something similar to get some first users to mine your pool.

I'm optimistic on you, you have potential, you just have to play your cards right first. Don't let it get you down and go for it. I wish you every success with your project. Every beginning is hard and only the tough ones cross the finish line.

People are very cautious to not get scammed and solo pools just mean "all-or-nothing", which makes them even more uber cautious. And again, imho the only way to earn reputation as a pool is by solving blocks. People will come mining once you have achieved this proof.

So please don't take it as personal offense against your new pool and your efforts. That was rather meant as a general statement. Go for your idea and make it great, I honestly wish you all the best luck and success!

Node height is available and instantly broadcasted through API and stratum. https://soloblocks.io/api/servers

No solved blocks if no trust. Fixed the trust. No hashrate. No blocks xD.

Thinking about closing the pool rn as nobody wants it and the large amount of defiance i've seen even if i'm in Bitcoin since 13 years.
Baremetal servers cost a lot for absolutely no reason. Mining is highly centralized right now.

I've got dual node failover on the mining pool, 32 Gb RAM and NVMe hard drives, stability is awesome at 0.5 Exahash on 1 pool at these difficulties.
I provide Full API, notably server health via https://soloblocks.io/api/servers

Most hash farms I know are unable to face the variance...
Discouraged by all of these and working had to address them still. Don't know what to do.

Every new pool will add in for decentralization, so that is to be appreciated. However, also anyone can decode the coinbase data regardless of the (solo) pool, since that data is exchanged via stratum. So there always was a way to verify what address is being rewarded with what amount (if the respective block wins) - and since the block hash is based on that input data, any tampering with the data will result in another hash value that won't meet the target difficulty.

Assuming on block level all is fine, you still have to always trust the pool operator to be fully operational, with up-to-date blockchain and capable to get your winning block out to the network as fast as possible. There are known and proven solo pools out there already, so as a new solo pool operator it will be hard to find trust and acceptance. In fact you can only earn trust with the count of solved blocks.

Answer has been made in pm : this functionnality is currently being made (implemented on the pool side, not tested yet, api not implemented, and frontend not implemented).
Not necessary for proof of work, mining software have this data. But for a pleasing experience will add it when I will have time to implement it.

I work for free. If they need functionnality, they can grant. And you have less than 100 Ths so it's not in my priority order, currently, in this bear market cycle.

If my contribution to a better decentralisation and fair job providing doesn't please you, you can Switch to shitty solo pools.

Edit : answer done in the thread and by pm where you haven't responded to my message (where I was asking WHAT EXACT information you needed (bestShare ever or also bestshare per block), I'm sorry if you didn't understood me with my poor english skills)

yes what now? Are you still planning or is the work done ? You should also watch your own support thread about the pool and give some helpful answers to questions like this.

Excuse me, I manage Soloblocks.io mining pool and have some answers.


Pool cannot submit your found block in a different bitcoin address and I've made a methodology to verify it.
It works only on soloblocks.io and you can try it on your own.

It was a problem until 2022 and I solved it on my solo pool.

Topic about it : https://bitcointalksearch.org/topic/m.60503248


Most of shares you submit on solo pools are useless as they don't match network difficulty. The only share that is sent to the network is the share that matches the difficulty and it is manifested by a winning block on the bitcoin blockchain.
On soloblocks you can see current realtime height of current job.


I'm planning to add the maxDiff on current block and maxDiff ever on informations on the Dashboard. You can verify it by yourself with your mining software as they calculate the shareDiff.


Sorry for this specific response but I've worked hard to address these issues and the work is done and online and I still have ZERO miners on the pool since 1 year.  

Yes. solo pool operators can manipulation of your submits and rippe off you at current start of the art in software of the pool side, eg:

1. Pool can submit  your found in a different bitcoin address to the bitcoin network. Because the pool got the coinbase data. This is quite wide practice in altercoin pools in terms of  my watching. Some pool operators are gangs and untracable, even by Agents.

2. Current miner softwares only got a message indicates the pool accepted this submit. But it does not provide information whether this submit has beem submit to the bitcoin network? or whether bitcoin network has accepted this submit? or confirmed this submit? This is an issue which give the pool operators a back door, I believe.  The altercoin pools and miner programs even got worst, they don't provide the height information of block. You never know your submits are accepted by the network or not.  They got webpage only indicate few second ago you did submit a share.

3.  After you submit your found to the pool, the pool firstly verify your submit with pool's share difficulty and then pool verify your submit with bitcoin network's difficulty. But, the pool never return a feedback information whether your submit is above the network's difficulty. This can be done easily in software, and this is a key issue in transparency of bitcoin network. Actually, the bitcoin core will return a message "under diff, sth like" if submit is below the diff.

So, there is a real risk in crypto coin mining business. When you ran a miner for one year, and got a good submit, then, ripped off or missed.
What can you do?  You have to work with reliable pool operator at first place.

Well, yes. That is why we raise the Warning Flags whenever some unknown newbie announces they've started a new pool be it solo, pplns, or pps. Trust must be earned!

Your BTC address is just being coded by the pool software as reward recipient vs the software pointing to a pool wallet to then be either sent to the solo miner or in the case of pplns, split up by the pool & distributed to the users. Where the reward is sent to and how much the pool takes as a fee are choices made by the operator when they set the pool..

In the case of -ck solo he coded the front end to take the address you provided and plug it into the block header to pay all but his 2% fee to you as the reward target instead of running through a pool wallet first. For Kano's solo pool you setup the payment address in your solo act, the pool wallet gets the reward and the accounting side of his software (KDB) transfers it (-0.5%) to your address on-file.

Either way the address you supply does *not* directly set where the block reward goes. The pool operator does and it all depends on how they code the pool.

Does this mean that the operator of a solo pool has the technical possibility of manipulation, e.g. to redirect the reward to himself in case of a block find? And this although the user of his pool had entered his own Bitcoin address as user name when started the mining? I would be interested from a technical point of view whether this would be possible in general. That would be disastrous, of course, because a pool operator could be a scammer. Can you please explain this in more detail? Thanks.

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.

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.

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.

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

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.

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 and @Kano

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

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.

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


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


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

it gives me


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


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


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.

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.

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.

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.

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.

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.



That's correct.

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.

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.

---

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

 

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.

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.

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