Hacker News Reader

> There is absolutely no way to 51% attack a major coin like Bitcoin for as little as $700k an hour. They are extrapolating from Nicehash's mining rental prices, but Nicehash doesn't have anything like the capacity you'd need.

You are correct - the nicehash-able column represents the amount of necessary hash power that is available via nicehash. If it's below 100% the attack cost is also greyed out.

Disclaimer: I build crypto51.

the grey you picked is pretty hard to distinguish from the black. The italics are nice though. Maybe add a little icon like this "no power" one: https://thenounproject.com/term/no-power/632253/

Nicehash has .99% of what you need to have 51% of the hashrate, not .5%. But that's still too tiny.

However.

You don't need 51% of the hashes to have the longest chain. The longest chain is a lottery. If you had 25% of the TH/s out there, there are 3x as many hashes you don't control as do. The odds are 1:3 that you will still find the next hash. If that weren't the case, there'd be no point at all in me having .0001% of the TH/s. I'd be better off setting the money on fire to heat my house.

Bitcoin doesn't have a consensus algorithm on two counts. The obvious one is that everyone takes the longest chain, regardless of whether everyone already agreed to a shorter chain. In Raft, your history can roll back if there's a partition. In Bitcoin, things can be rolled back even if everyone is online. I need one attack (rewrite history), not two (rewrite history + DOS attack), and because of that, nobody but my pocketbook notices if I try and fail.

The second one is that there is no consensus on what transactions to include in the next hash. Any hasher could blacklist transactions that are unfavorable to them without really affecting their odds of finding the next hash. I think it's assumed that it's not in the interest of either mining hardware owners or frequent cryptocurrency spenders to do this, as they would destabilize their own investment. That only borrowed hardware would be used that way, and on short bursts of purchases. But is that really true? Or is there a zero-day attack out there already being used or waiting to be found?

I'm thinking of the epic embezzling scandals that have turned up. How many people out there were never caught, or were insufficiently prosecuted? Employees are usually subject to the laws where the office is located. These people could be on the other side of the world.

If you had 1/4 the hash power, it's true that you have 1/4 chance of creating a block before anyone else, but to be clear, doing that once isn't enough to do a double-spend attack of a transaction with some N confirmations (usually people would aim for N=6). There's only a 2% chance an individual attempt would pull that off for 6 confirmations in a row when using 1/4 the global hash power, and the whole time you're attempting this, your hash power isn't making money mining unless you succeed. On average, you would make $144,000 just from the block rewards from mining for that much time with 1/4 global hashpower, so the expected amount of failures are very expensive in opportunity costs. If I'm doing probability right, then at a 2% chance, you could expect to fail about 25 times on average before succeeding, so 25 failures adds up to $3.6 million of expected opportunity cost. (This isn't counting the cost in acquiring 1/4 global hashpower to begin with.) You would have to double-spend a lot of transactions to make that worth it, and people are probably going to wait for more than 6 confirmations on bigger transactions, which means a much larger attack would have to be done to target those.

If you add opportunity cost and renting cost, you are double counting.

Assuming you can repeat your "totally legit" setup transactions until you succeed, with minimal cost other than rent, you would need to take more than either the opportunity cost (otherwise it's better to just mine), or the renting cost (otherwise you're still losing money).

Adding opportunity cost and renting cost isn't double counting.

Opportunity cost is the foregone block rewards that you lose because you didn't submit your blocks, because you were holding them hoping to build a long enough chain to double spend. When you fail, that reward that you would have earned is gone forever.

Renting cost is the actual $ outlay that it costs you to rent the hash power necessary to perform the attack.

So I have a fun thought. You can cantrip your ill gotten coin into more compute. Assuming you could work your way up and own every exchange before anyone caught on (not realistic), could you work up enough funds to buy enough general cloud compute to overtake BTC?

Why are you assuming that hashrate would be obtained legally?

If you're already assuming criminality, go all out! BGP route hijack the unencrypted, unauthenticated mining traffic and call it your own.

Cost is basically nothing to do so, other than some jail time.

Can you clarify what you mean by hijacking mining traffic? 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. You can't substitute the transactions in the block/solution without redoing the PoW.

That's why miners can't steal a pool's solutions to begin with.

All miners connect to pools using a protocol called stratum. This is JSON piped over TCP with newline terminations. There is no authentication for this protocol and no encryption. You can simply intercept the communication here and have all the miners on a pool actually mine for your replacement pool, and nobody will ever catch on until its far too late.

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

When I was toying around with mining some alt coins with GPUs a few years back I had the thought when joining a mining pool on say supernova, what is to prevent someone from doing an attack and convincing the pool to send my coins to them instead at a level 'under the hood' and beyond my understanding. Or get the entire pool to act in a way that is for their own personal gain.

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.

If you kept all of the coins from a pool, you'd be caught.

But would I ever know if you lied about the pool's GH/s rate and kept half of the coins?

You can probably assume that most pools are skimming or cheating in some way, they'd never be caught.

Not going to claim they aren't skimming, but is it not possible to calculate expected number of blocks from declared GH/s, expected earnings from user provided MH/s and tell if the pool is excessively "unlucky"?

Yeah I thought of that too after posting. I think it comes down to how transparent the pool is with their data.

The obvious thing to do would be to tell everyone that my 500 GH/s pool is 400 GH/s, and reward everyone an 80% share on every hash. If you're sophisticated enough you might notice that my pool is mining blocks about 25% above what you'd expect, but how many data point do you need for that, and it's statistical, so I'll have runs of good or bad luck.

Another option is to dilute the pool of contributors, but again you might be able to detect that either I'm misreporting your hash rate, or the sum of all contributions doesn't line up.

Assuming I give you enough tools to figure any of this out.

If you report the pool's hash rate as lower, the users should demand a higher fair share, as they know their own hash rate.

Either way, if a user knows his hash rate, he can calculate expected earnings and their presumed share. You could fudge a bit, but go too much, especially on a large pool, and it will be apparent. There are probably lots of users doing calculations, willing to call you out.

> If you report the pool's hash rate as lower

err, right. If you want to convince people they're getting a fair share, you have to downplay their contributions, and since they know what they did you have to make the pool bigger, not smaller. How long would it take to notice someone was fluffing the pool by 10%?

The variance month to month is far higher than that for most pools. Nobody would ever notice, trust me.

Yeah that’s what I meant by the statistical comment.

My hardest class in college was statistics, and mostly I learned that humans suck at them.

I was binging math videos recently and I got to one where one guy made a list of “random” heads or tails, and then the other guy guessed them and got like 60% right. He was disappointed because he often does better.

Humans, he asserted, will never write more than 3 (or was it 4?) heads in a row because they feel they aren’t random enough. And because if this, over half of the possible patterns are never seen.

Which is also why, when a test that’s failing 10% of the time, my coworker who thinks he just fixed it will run the new version five, ten times and claim victory... only for it to fail four times in a row the next day.

Okay I see what you mean about replacing the work assignments going to the miners -- if you could tell them to solve a different block/fingerprint (hash of new block + previous block) and receive their output, then you can steal their hashing power. But I'm still not sure what you mean here:

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

You're fundamentally missing the point somehow.

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.

Pretty sure I'm not missing the point, because that's exactly what I said, in different words.

I specifically agreed that, if you can replace the assignment given to the miners ("replace the pool and announce their own work to you"), and see the output, then you can steal the work. It was in this paragraph:

>>Okay I see what you mean about replacing the work assignments going to the miners -- if you could tell them to solve a different block/fingerprint (hash of new block + previous block) and receive their output, then you can steal their hashing power.

That is an agreement with your:

>In a route hijack, an attacker can replace the pool and announce their own work to you, and receive all results you produce.

That is me communicating agreement that that's the attack that "makes sense" as in your sentence here:

>They're going to replace the work that's sent to you in the first place, because that's what makes sense.

I made my original because it sounded like you were saying a miner not (separately) authenticating their output to the pool would be an issue, which I now see you (always) agreed is orthogronal; my only objection in the follow-up was that your comment was addressing something different than I originally raised:

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

So, if I agree with you on every question of what and where the threat is and is not, and said so with slightly different words than you did, what point do you think I'm fundamentally missing?

(I am not informed about what the typical arrangement is to spread out the stochastic reward a pool earns over its members, so I am making no claims on this front)

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?

> You can simply intercept the communication here and have all the miners on a pool actually mine for your replacement pool, and nobody will ever catch on until its far too late.

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?

Yes. The response time to that will be much less than the time to perform an attack with that hash rate though. We’ve seen people mine for literally 4 months on a broken pool that produced no income before they noticed.

Poster is probably referencing this BGP attack on a mining pool.

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

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

That's not how any of this works. There's no massive mining traffic. Most of the mining is done in private data centers. They only broadcast their transactions when they "solve" the hash.

These private mining datacenters typically get their block templates from pool servers. Miners communicate with the pool servers over the internet. Control the pool server control the mining power.

This is exactly how it works! Most miners are connected to pools like slushpool, f2pool, etc over unencrypted an unauthenticated links. If you can modify this traffic you can steal the hashrate, because you can modify the work being sent to the miners before they do any hashing.

Is it clear that an attack on a crypto currency would be illegal?

I suppose it might fall under wire fraud... Like some hacking does?

How about a malicious country/government that is capable of doing this?