Bitcoin Forum
December 03, 2016, 07:51:36 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: How exactly would a 51% attack work?  (Read 17741 times)
skinturtle
Newbie
*
Offline Offline

Activity: 28


View Profile
August 21, 2012, 06:08:47 PM
 #41


Subsidy or not the cost is real.  At this point there is no economic demand for an 8TH network.  Maybe not even enough for a 1 TH network.  The current network (at a guesstimate of 2MH/W, $0.10 per kWh and $1 per MH capital cost) consumes nearly $10,000 daily in electrical power and burns through another $1000 in depreciating hardware).  That simply isn't sustainable given the tiny amount of economic activity actually occurring. 

Since we're bringing things back from the dead:

Assuming 200,000 btc trade hands at lets say an average of $10, (just at mtgox) thats 2 million per day, with mining costs of 11,000 per day. Is this not a favourable ratio?


Probably not.  Just because 200K BTC trades ON the MtGox exchange (which has nothing to do with the blockchain) doesn't mean an attacker could profit from all that.

So an attacker has a large number of BTC.  He deposits it on MtGox and then starts building an "attack chain" in secret.  Even if he converted the 200K into $2M he can't withdraw that in a day.  Tier 3 verification (requires requires an apostle seal from your state govt for US residents) is still limited to $100K per day ($500K per month).  So an attacker "could" in theory profit $500K in 5 days.  Of course that ignores the effect of an additional 50K BTC in selling pressure driving down the price.

However in 5 days an honest miner could generate $225,000.  So the ratio between good and bad is much smaller.  Also the only way you are moving $500K in 5 days is by bank wire which is going to leave a trail.  So $225K honestly or $500K + $225K = $725K and risk of going to prison?  Factor in some delays by MtGox on wires and it may require more like 10 days to ensure you have sufficient funds which makes the attack more like $450K honestly or $950K + prison.  Worse say there is a mixup or an AML/KYC hold by one of the banks for 15 days.  Ouch more and more hashing power just to get this "easy" $500K.

Of course even if successful you are now a wanted man and likely wouldn't get more than one attack.  Next month if you tried again (even with a new account) MtGox likely would have lower limits or more stiff validation so it is a low return of then $20M or so you spent on hardware.  Plus nobody is going to run a 10TH/s farm by themselves you are talking an entire crew (admin, technical, electricians, security - you weren't going to leave $20M unguarded in some warehouse were you).  Seems a pittifully small "score" divided 5? 10? ways to risk prison. 

Much easier to just offer 7% returns and have people hand you 10x as much with no strings attached. Smiley

Satoshi designed it well.  The economic disincentive for doing the wrong thing makes it very unlikely there will ever be an economically viable 51% attack.  The only real threat is a non-economic 51% attack (where the attacker sees the attack as simply an unrecoverable cost to destroy Bitcoin).

Thank you for explaining this so well, I'm new to Bitcoin so I'm looking into all the flaws before I dive in.. So thank you.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480794696
Hero Member
*
Offline Offline

Posts: 1480794696

View Profile Personal Message (Offline)

Ignore
1480794696
Reply with quote  #2

1480794696
Report to moderator
1480794696
Hero Member
*
Offline Offline

Posts: 1480794696

View Profile Personal Message (Offline)

Ignore
1480794696
Reply with quote  #2

1480794696
Report to moderator
Elwar
Legendary
*
Offline Offline

Activity: 1932


www.bitpools.com


View Profile WWW
August 21, 2012, 06:16:40 PM
 #42

I did this once. Went to that bar in Orlando that accepts Bitcoin. Bought a beer and some nachos and paid in Bitcoin. What they did not know is that I overclocked my CPU at home to 66MHz and executed the 51% attack perfectly.

By the time I walked out, the Bitcoin I had used to buy the beer was back in my wallet and nobody was the wiser.

Though when I got home, my overclocked computer was fried. Lost all of my favorite gifs and clean Win3.1 install.

http://www.bitpools.com
Pool your bitcoins with others. Vote on solutions using the Bitcoin blockchain. Keep your bitcoins in your cold storage until you find a solution you like.
Links and Reviews of useful every day places to spend bitcoins: https://bitcointalk.org/index.php?topic=943143.0
SapphireSpire
Member
**
Offline Offline

Activity: 63

IP Is The Real Piracy


View Profile
March 10, 2014, 06:49:38 PM
 #43

An attacker would only need 51% of the total network hash rate if all miners were working cooperatively to solve the next block. Not just working in pools but collectively focused on executing the exact same process. But because miners are competing with each other, running independent and probably redundant processes, an attacker only needs to be faster than the fastest mining node on the network, either using a single fast node or a pool of cooperating nodes with a combined speed that is faster than the fastest miner on the network.

I've read the original whitepaper for Bitcoin and I've read the Bitcoin wiki and many other sources but I still can't figure out how the hashing algorithm is supposed to validate new transaction data. All it does is make it difficult to produce the next block. The validity of the data still depends on consensus- trusting the claims of the majority of nodes on the network. So an attacker only needs to create a pool of nodes that exceeds the number of existing nodes on the network, effectively doubling it, in order to subvert the validity of the blockchain.

1Phb3mhPHVoJqYi6qYbD4jxontd6e2qaDa
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 10, 2014, 07:26:14 PM
 #44

An attacker would only need 51% of the total network hash rate if all miners were working cooperatively to solve the next block. Not just working in pools but collectively focused on executing the exact same process. But because miners are competing with each other, running independent and probably redundant processes, an attacker only needs to be faster than the fastest mining node on the network, either using a single fast node or a pool of cooperating nodes with a combined speed that is faster than the fastest miner on the network.

That is 100% incorrect.  In the future how about phrasing things you don't know as a question.  There are no redundant attempts on each block (baring the implementation issue at a specific pool where the pool incorrectly issues the same work to more than one worker).
Redtea
Newbie
*
Offline Offline

Activity: 27


View Profile
March 10, 2014, 07:34:14 PM
 #45

The blockchain should have checkpoints every X blocks to limit the time the attacker has to act.  Then if you wait 2x blocks you should be pretty safe.  Blocks 1 to x are checkpointed by block x+1, which itself will be checkpointed by block 2x+1.

I think the bitcoin client already does this.

There are manual checkpoints hardcoded with each release.  I'm proposing a much higher frequency of checkpoints.


You really think so? -_-
SapphireSpire
Member
**
Offline Offline

Activity: 63

IP Is The Real Piracy


View Profile
March 10, 2014, 07:48:52 PM
 #46

An attacker would only need 51% of the total network hash rate if all miners were working cooperatively to solve the next block. Not just working in pools but collectively focused on executing the exact same process. But because miners are competing with each other, running independent and probably redundant processes, an attacker only needs to be faster than the fastest mining node on the network, either using a single fast node or a pool of cooperating nodes with a combined speed that is faster than the fastest miner on the network.

That is 100% incorrect.  In the future how about phrasing things you don't know as a question.  There are no redundant attempts on each block (baring the implementation issue at a specific pool where the pool incorrectly issues the same work to more than one worker).
I may not know much about Bitcoin but I know a lot about computers. There is no way multiple instances of the same hash algorithm running on independent computers can avoid executing the same code on the same values. It's extremely redundant. It's only in the case of a pool in which the workload of a single process is divided between it's members that redundancy is nearly eliminated.

Next time you want to refute a claim you should make an effort to explain why you think it's wrong.

1Phb3mhPHVoJqYi6qYbD4jxontd6e2qaDa
bl0ckchain
Member
**
Offline Offline

Activity: 98


View Profile
March 10, 2014, 08:19:04 PM
 #47


There's some great information here explaining the 51% attack.

One thing I didn't see mentioned was how Satoshi was planning on building a 51% attack defense into the code. But he got spooked and vanished after Gavin informed him that he was going to talk to the CIA/feds about Bitcoin. A few years after Satoshi's disappearance, a young Canadian programming student studied the existing code and engineered the missing 51% defense system that Satoshi was unable to complete.

This is the system currently integrated in Goldcoin (GLD).

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 10, 2014, 09:00:41 PM
 #48

I may not know much about Bitcoin but I know a lot about computers. There is no way multiple instances of the same hash algorithm running on independent computers can avoid executing the same code on the same values. It's extremely redundant.

Once again making false statements as fact.  Why not say "I believe it is redundant" or "I can't see a scenario where miners unknown to each other don't duplicate work accidentally?".  You state you don't know much about Bitcoin but you feel confident about making absolute statements of fact about something you don't know much about?

The different computers (1, 2, a trillion it doesn't matter) use different inputs and thus (barring some isolated implementation errors) never attempt work which has already been attempted.  Miners aren't hashing some random value, they are hashing the blockheader and Satoshi designed it so there would be no duplication of work.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Even if everything else is the same in a block, the coinbase tx for each miner will be unique and thus the hash for that tx will be unique and thus the merkle tree will be unique and thus the merkle root hash will be unique and thus the blockheader will be unique.
SapphireSpire
Member
**
Offline Offline

Activity: 63

IP Is The Real Piracy


View Profile
March 11, 2014, 06:04:23 AM
 #49

I may not know much about Bitcoin but I know a lot about computers. There is no way multiple instances of the same hash algorithm running on independent computers can avoid executing the same code on the same values. It's extremely redundant.
The different computers (1, 2, a trillion it doesn't matter) use different inputs and thus (barring some isolated implementation errors) never attempt work which has already been attempted.  Miners aren't hashing some random value, they are hashing the blockheader and Satoshi designed it so there would be no duplication of work.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Even if everything else is the same in a block, the coinbase tx for each miner will be unique and thus the hash for that tx will be unique and thus the merkle tree will be unique and thus the merkle root hash will be unique and thus the blockheader will be unique.
I didn't say miners attempt to do work that has already been done. I said they often do the same work in parallel. The page that you linked to confirms what I'm saying:
"Given just [the header] fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win."
It doesn't matter if the hashes are the same or not. The fastest CPU (or group of CPUs) almost always wins simply because it's faster. My point is further confirmed by BTC guild's finding four consecutive blocks with a few minutes.
http://hackingdistributed.com/2014/01/01/btc-guild-selfish-mining/

The article goes on to say:
"However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network."
So you're right about the blocks being different. But they aren't completely different. In fact, the vast majority of transaction data is the same. And, again, it doesn't matter if the hash results are different, it's redundant because the same algorithm is ultimately being applied to multiple instances of the same transaction data.

1Phb3mhPHVoJqYi6qYbD4jxontd6e2qaDa
ning
Full Member
***
Offline Offline

Activity: 173



View Profile
March 11, 2014, 06:12:19 AM
 #50

...

So IMHO the only reason to 51% the network is to kill it.  A currency has value only if its value can be trusted.  Bitcoins which can disappear at the will of an attacker have no value.  The collapsing price, falling hashrate, and reluctance of merchants to accept them after a 51% attack will kill Bitcoin.

royalfestus
Member
**
Online Online

Activity: 112


View Profile
August 29, 2016, 08:24:36 PM
 #51

Is this post of 2 years as relevant as now?

                 FREE DISTRIBUTION TO BTC HOLDERS         NEW CONSENSUS ALGORITHM
● Byteball ●    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
               REGULATORY COMPLIANT ASSETS               UNTRACEABLE PAYMENTS
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!