Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cost of a 51% attack for different cryptocurrencies?

crypto51.app

Post reply on HN
Print view View original

121–130 of 134 posts

Re: Cost of a 51% attack for different cryptocurrencies?

#121

Post by gambler »

hinkley wrote: post #113
gambler wrote: post #51

Computational power is not a good proof of anything. It devours energy and disproportionately rewards weird market actors (like people with custom mines ASICs). I always wondered whether storage could be used as proof of stake. It might use less energy and it probably will have much better effect on the IT industry as a whole. First, mining ASICs are not general computational devices and cannot be used for anything u…

There are some IPFS people who talk about proof of having stored files, but I was never satisfied with their fraud detection techniques. Can you prove that one copy of your data is being stored? Yes. Can you prove that three copies of your data are being stored? I haven't seen any scheme that can detect if I'm pretending to be multiple people, serving files from the same disk array over multiple network connections.

The question is not whether it's possible to pretend to be multiple people. The question is whether storing a large file places some fundamental restriction on how much activity a node can conduct on the network. (I.e. is there a cost of doing business that limits your from just spamming transactions at nearly infinite rate.)

Re: Cost of a 51% attack for different cryptocurrencies?

#122

Post by RL_Quine »

labawi wrote: post #118
RL_Quine wrote: post #84

Earlier quoted context omitted.

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 s…

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

Re: Cost of a 51% attack for different cryptocurrencies?

#123

Post by hinkley »

labawi wrote: post #120
hinkley wrote: post #113

Earlier quoted context omitted.

There are some IPFS people who talk about proof of having stored files, but I was never satisfied with their fraud detection techniques. Can you prove that one copy of your data is being stored? Yes. Can you prove that three copies of your data are being stored? I haven't seen any scheme that can detect if I'm pretending to be multiple people, serving files from the same disk array over multiple network connections.

> Can you prove that three copies of your data are being stored? In the context of IPFS, I'm not sure. If you want to use the (crypto) network as distributed storage, you can shard and encrypt the data (at you 3x or whatever redundancy) and the storage provider is forced to store all of it, at least once. Some incentives on data durability and availability may be enough to get a reasonable baseline.

If I didn't care how complicated the client is, sure.

I can do something reminiscent of "m of n" control tools, FEC or striping algorithms, but now the client is doing multiple fetches and matrix multiplication on every single request.

If I'm just trying to make sure there are 3 copies of my home page on IPFS, then I need 3 copies of the same file in three locations. And those locations all need to be online when I want to challenge them.

The Bitcoin protocol is designed around low availability of individual nodes and inference of consensus. Any 'proof' has to be uploaded while you're connected. Uploading a proof (of work, stake, whatever) to the network proves you did something, there is no need to challenge that fact, and you can disappear for hours or forever. No voting, no challenges.

Proof of storage requires challenges, which requires availability (well, storage also requires availability, otherwise what's the point?). If you insist that almost everyone is online, then you open the door to other consensus algorithms. Ones that can, for instance, handle non-repudiation.

Re: Cost of a 51% attack for different cryptocurrencies?

#124

Post by hinkley »

labawi wrote: post #119
RL_Quine wrote: post #114

Earlier quoted context omitted.

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.

Re: Cost of a 51% attack for different cryptocurrencies?

#125

Post by Arnavion »

RL_Quine wrote: post #104
Forbo wrote: post #98

Earlier quoted context omitted.

GPUs actually have a significant disadvantage on RandomX. Their hashrate is much lower than what you'd get from a CPU. Edit for more info: https://monerobenchmarks.info/ According to this site, an overclocked Titan RTX gets about the same hash rate as a stock AMD FX8370E at nearly half the TDP.

Replace GPU with CPU in my answer. It applies to all of the algorithms in one way or another. ASIC resistant is an oxymoron.

ASIC-resistant specifically applies when you're talking about using ASICs as ASICs. If you're using ASICs to emulate CPUs (soft microprocessors), that is usually much less efficient than what the ASIC is capable of.

Re: Cost of a 51% attack for different cryptocurrencies?

#126

Post by henryfjordan »

xur17 wrote: post #102
Meekro wrote: post #60

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 can see here[1] that nicehash has about 500 PH/s (500,000 TH/s) available for rent. However, Bitcoin's total hash rate right now is 100,000,000 TH/s[2]. This means that if you rented out the…

> 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 bui…

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/

Re: Cost of a 51% attack for different cryptocurrencies?

#127

Post by labawi »

hinkley wrote: post #124
labawi wrote: post #119

Earlier quoted context omitted.

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 statist…

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.

Re: Cost of a 51% attack for different cryptocurrencies?

#128

Post by labawi »

hinkley wrote: post #123
labawi wrote: post #120

Earlier quoted context omitted.

> Can you prove that three copies of your data are being stored? In the context of IPFS, I'm not sure. If you want to use the (crypto) network as distributed storage, you can shard and encrypt the data (at you 3x or whatever redundancy) and the storage provider is forced to store all of it, at least once. Some incentives on data durability and availability may be enough to get a reasonable baseline.

If I didn't care how complicated the client is, sure. I can do something reminiscent of "m of n" control tools, FEC or striping algorithms, but now the client is doing multiple fetches and matrix multiplication on every single request. If I'm just trying to make sure there are 3 copies of my home page on IPFS, then I need 3 copies of the same file in three locations. And those locations all need to be online when I w…

I wasn't thinking of IPFS, rather a way to have a proof-of-stake storage system doing actually useful work. I think I've seen at least one, though I'm not sure of it's current state.

Re: Cost of a 51% attack for different cryptocurrencies?

#129

Post by hinkley »

labawi wrote: post #127
hinkley wrote: post #124

Earlier quoted context omitted.

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 statist…

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%?

Re: Cost of a 51% attack for different cryptocurrencies?

#130

Post by RL_Quine »

hinkley wrote: post #129
labawi wrote: post #127

Earlier quoted context omitted.

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.
Post reply on HN