Bitcoin gold was a fork to try and decentralize mining. It changed to a proof of work that is supposed to be ASIC resistant. It looks like the typical situation is mining by GPU for equihash (BTG PoW).
BTG hashrate is at ~30MH/s at the moment, where Zcash's hashrate is at ~486MH/s.
I don't have the numbers off hand, but it'd be interesting to see how many GPUs you'd need to pull of a double spend against BTG and if any of the other equihash coins saw a drop off during the attack.
It'd be really interesting if it wasn't a rental attack, but an invested miner just switching over to BTG to achieve the hack.
They reversed 22 blocks, the recommendation is to increase the # of confirmations to rely upon to 50. If you are trying to react to 51% attack doubling the number of confirmations only doubles the cost of attack, and the attacker likely just doubled the number of BTG they have. If they can pay the electricity/rental cost for the attack they have enough BTG to execute the attack in a cost effective manner again.
You can rent hashing power on Nicehash, which currently has ~77MSol/s available for rent. I'm not 100% familiar with how the auction process works, but it looks like I could purchase 26MSol/s via a fixed contract for 1 hour for ~1BTC.
Am I misunderstanding something here, or can I maintain a 51% attack right now for ~$8k an hour. This can't be right.
It is risky, but it is right, that's exactly why took a while to happen. A relatively small botnet can overtake many smaller coins in hash power in no time, that's the hypothesis where I'd put the money.
It should come lower than that...rental price seems to be around 0.5 BTC/MSol/day, so the price for one hour would be 0.5 * 26 / 24 = 0.54 BTC, roughly $4k
I was curious about the cost as well, so I ran some rough numbers.
417.5 BTC/GH/day for equihash if you're renting from nicehash [1].
Block interval 10 minutes [2]. 144 blocks per day target yields 0.0869 BTC/block, so cost of the 22 block reversal was ~1.91 BTC, or roughly $15k.
I'm curious if this was done as one large deposit, or many smaller deposits. I've imagined a system where block confirmations required are based on a computed cost of attack done like I did above, which would be pretty effective for very large single transaction double spends. A bit trickier to handle multiple deposits spread across multiple user accounts.
As the space matures I'd love to see a company that offers double spend insurance for a given tx.
For example changes could wait for 10 minutes worth of blocks then request a quote for double spend insurance. The company evaluates the probability of a double spend and maybe even has a couple standing contracts with rentable hashing power to be able to target smaller PoW chains and prevent any double spend attack.
There are lots of interesting and cool problems to be solved in evaluating the safety of a given tx. Unfortunately I don't know if the space is mature enough that exchanges would actually use the service.
> If the exchange is aware of the attack, they may also freeze his account, so that all the funds will be locked inside the Exchange. A failed 21 block attack performed with a 10,000 BTG deposit where the Exchange freezes the account in time will result in a 10,262.5 BTG loss for the attacker. (From link.)
That sounds problematic. If I deposited coins and the exchange determined I was attacking them (how does that work beforehand?) to confiscate my money I'd be pretty miffed.
Not only that, but also an attacker can wait until the money is "safe" outside the exchange before revealing the attack. If the attacker really has more than half of the hash rate, there's no time limit; the malicious chain will always be longer than the innocent one.
It's only odd if you look at the community part of a decentralized coin as only the miners. You're missing the other critical parts which are its users and the exchanges.
A cryptocoin is worthless to miners if it cannot be exchanged, and it's worthless to exchanges if no one wants to trade it.
This introduces the "time" component of the attack increasing its riskiness. The longer you wait until releasing the chain, the more time there is for events to happen that might completely thwart your attack.
Except Bitmain has announced and will be shipping to preorders the first Equihash ASIC (Antminer z9) in July... only 3000 z9's would be needed to equal 30 Megahash, which would be $6M at the z9's $2k price tag. Bitmain obviously has been mining themselves with the z9's for a while, so I would bet that they noticed this and jumped on it before shipping their "lightly used" units out.
I run around 630 sol/s per 1080ti GPUs, each costed me around 950$. You'd also need to add the electricity in there, I think the challenge is to control an infrastructure being able to do over 15 MH/s as opposed to having the capital.
Not every distributed consensus algorithm is happy with 51%. If you increased the minimum to 60% you’d increase the number of machines the attacker requires by 50%.
If 100 machines play fair, >50% requires 101 evil machines, but >60% requires 151 evil machines.
I think you're misunderstanding the meaning behind a 51% attack?
An honest network participant will accept the chain with the largest accumulated proof of work. This is necessary to resolve forks of the chain, which are a natural occurrence.
A 51% attack means that the attacker can create a chain with more work than the rest of the network.
The idea that you can say "we require 60%" makes no sense by itself - you have to say what you actually mean in the context of a competitive and adversarial distributed proof of work blockchain network...
Maybe you have some ideas how to avoid history-rewriting attacks, in which case you should write a white-paper and launch your own sh1tcoin or ICO (only half joking).
Thank you for helping me put into words what bothers me about crypto currency. We’ve deployed an AP algorithm for financial transactions. That’s not fixable.
https://forum.bitcoingold.org/t/double-spend-attack-on-excha...
Bitcoin gold was a fork to try and decentralize mining. It changed to a proof of work that is supposed to be ASIC resistant. It looks like the typical situation is mining by GPU for equihash (BTG PoW).
BTG hashrate is at ~30MH/s at the moment, where Zcash's hashrate is at ~486MH/s.
I don't have the numbers off hand, but it'd be interesting to see how many GPUs you'd need to pull of a double spend against BTG and if any of the other equihash coins saw a drop off during the attack.
It'd be really interesting if it wasn't a rental attack, but an invested miner just switching over to BTG to achieve the hack.
They reversed 22 blocks, the recommendation is to increase the # of confirmations to rely upon to 50. If you are trying to react to 51% attack doubling the number of confirmations only doubles the cost of attack, and the attacker likely just doubled the number of BTG they have. If they can pay the electricity/rental cost for the attack they have enough BTG to execute the attack in a cost effective manner again.