Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Or, you need to spend a lot of resources to do the attack even if it's the case that you get that money back when you succeed.

There is a word for this. We call it risk.





I'm not sure I'd call this risk. Risk would be "you can invest the money, but you might not get it back" however the above is referring to the "a 51% attack absolutely works but you need a shit ton of money to do it" aspect instead. This makes it capital intensive, not (necessarily) risky.

The fact that it succeeds does not mean that you get the money back (eg the price of monero could drop if that happens). You may also have miscalculated some parameters in all this or something unexpected happens (where human factor is involved). So there should always be risk involved imo. Otherwise I agree, even in a probability 1 success situation this would still not be called "cheap".

Agreed, no such thing as a real-world investment with truly 0 risk.

It is absolutely risky. Your facilities can burn down once the ASICs arrive and before they are turned on, or your employees simply steal them for their own uses. Heck, you can have a fire once they get powered-on, because a power cable was poorly made. You might get sent the wrong product, or you could be ghosted without a delivery.

Expensive is a better fit than capital intensive, because there are massive ongoing costs to actually perform the attack, electricity for one.

If you want to understand the risks for a project, pretend you are at arms length and are being asked to fund the project 100% up-front. You'll find a huge list of risks very soon.


This is why I didn't say it made the investment risk free, I said being capital intensive does not make something (inherently) risky. There is no such thing as an investment without risk, but how risky it is is largely orthogonal to how capital intensive it is, and the above was talking about the latter so using the term "risk" for that half is not a great correction.

Having the power to deny others to mine blocks does not mean that you can obtain the tokens from their wallets. Miners can't sign transactions on users' behalf. You can rewrite all of history but then no exchange will accept your version of it to let you exchange the tokens for fiat. Also this will almost certainly crash the price of XMR substantially. And later people will be able to fork/restore the original version. The technological side of the blockchain is only part of the consensus/trust/market/popularity. People are the other part, and people will not pay the attacker for their successful attack.

The attacker doesn't need to steal tokens. They just need to short the token while they sufficiently disrupt the network to drive down the price. They get the money and your tokens become worthless.

I was completely wrong about the cost. XMR mining rewards amount to only $150k/day.

At the height of the attack, Qubic (the company) paid people up to $3 in QUBIC for every $1 of XMR they mined through QUBIC, and they achieved around 33% of XMR's hashrate which was sufficient to mine the majority of blocks for a few hours.

If they were forced to buy back all those QUBICs they paid out, this might have cost them ~$100k/day. But thanks to the media attention it's likely that they didn't need to buy anything back and actually were able to emit more than they otherwise could have.

XMR needs to adapt -- switch to PoS, or ASICs-based POW, or a hybrid of both.


Controlling 51% of XMR costs ~$30M per day, you'd have to short a huge amount of XMR to make that worthwhile. Who would be the counter party and how would you do that anonymously?

The attack itself is unprofitable, the "profit" for Qubic is the publicity they get. (or at least that's what they're betting on)


Monero has a theoretical market cap of $4.7B USD and daily volumes >$100M USD. I wouldn't recommend taking that short position in one go but over a few days and a few exchanges I wouldn't see a problem acquiring a very large short of the token.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: