That's why miners can't steal a pool's solutions to begin with.
> If you mean the traffic of mining pools communicating their solutions to the pool's "mother brain", those are already cryptographically attached to a solution that pays out to specified addresses.
That's not correct in practice. There's no authentication of the work going to the miner at all, so an attacker can just change the destination before the miner even sees the work.
I know there had been guides on how to set up your mining rigs, setup the batch files etc. These were all guides written by other people and I could see how in this newly created space there was room for nefarious actors to try to convince people to mine in a pool, but not give them the rewards they deserved or scammed them in some other way.
I also thought about someone hacking entire pools' hash-rates to be used for their own purposes rather than trying to figure out the next block on whatever chain it was running. This would allow someone to 'steal' the hash power of expensive rigs and redirect the power to their own wallets.
My understanding of all these protocols is very limited to what is regurgitated from others. When it comes to reading the bitcoin whitepaper I was only able to comprehend up until section 11 on page 6 where it got into the calculations, at which point I got lost as I am not that good at math.
Thank you for the insight.
But would I ever know if you lied about the pool's GH/s rate and kept half of the coins?
>>If you mean the traffic of mining pools communicating their solutions to the pool's "mother brain", those are already cryptographically attached to a solution that pays out to specified addresses.
>That's not correct in practice. There's no authentication of the work going to the miner at all, so an attacker can just change the destination before the miner even sees the work.
I was referring here to the solutions the miners send out. That does not need to be authenticated because it's already attached to the block they were solving for -- i.e. it is a proof of work valid only for a specific block. If they received the correct block and nonce range to check, then the solutions are useless to anyone else. Diverting their traffic would just reduce the mining pool's hash power, not give it to anyone else.
So yes, I see how you could steal the miner's hash power if you could replace the assignment the pool head was giving them, and then see the output, but I don't think it's correct to say that solutions are vulnerable to being stolen after getting the correct assignment "because they don't authenticate" -- the proof of work is only valid for that block, and so could only be destroyed, not stolen.
When you connect to a pool, you give them absolute trust over what you're mining using your hardware with the expectation that they will pay you for it later. In a route hijack, an attacker can replace the pool and announce their own work to you, and receive all results you produce. You can not distinguish this with the normal behavior of the pool and will be robbed, and your work can be used to do whatever the attacker wishes.
The output of the work being loosely "authenticated" with the pool by virtue of the work being non-transferable is entirely orthogonal. Nobody is going to be taking that because it's worthless, as you correctly point out. They're going to replace the work that's sent to you in the first place, because that's what makes sense.
But if the (non-principled) value of mining 20 blocks is 20 block rewards, then there we have the cost of buying 20 blocks (assuming miners non-ideologically sell out).
Assume they would not voluntarily sell out, then any flaw in the pooling mechanism (by which miners dilute the rewards into a steady income) which allows 1) other work to be assigned to the miner 2) while still receiving their intended addresses, would allow an attacker who is able to hijack the work assignments, to buy those 20 blocks for the price roughly on the order of ~ 20 block rewards, by 1) hijacking the work assignments 2) payout out the miners the correct expected amounts so that they hopefully don't notice
Is that correct?
Depending on what you consider fat too late, doesn't the pool verify the solutions, and provide OOB statistics, where people would notice over time that they get 0 credits?
"BGP Hijacking for Cryptocurrency Profit" - https://www.secureworks.com/research/bgp-hijacking-for-crypt...
An attack like this could be repurposed to perform reorgs with 51% of the mining power as the stratum pool server decides what previous block to mine on. No idea if mining pools or the stratum protocol has added countermeasures to prevent such an attack in the future.
Not really. There's some discussion about Stratum2 having stronger authentication, and systems like BetterHash to take away a lot of the centralizing impacts of pools by having people create their own work, and only centralizing the payouts for that work. It's a bit of a challenge because there's such a huge range of hardware out there with incomplete implementations of stratum in closed source forks of mining software. You basically have to wait for it to just be obsolete and replaced because there will never be updates.
