39

Disclaimer: I believe this question may be primarily opinion-based and not very appropriate for this site, but there are a number of technical misunderstandings that can be clarified along with it, so I'll give it a shot. There are many nuances involved here, and I fear that a large part of them didn't reach as much of an audience as the exchange announcing ...


27

The distinction is of theoretical importance only. But if the attacker controls exactly 50%, then it's true that the attacker will eventually catch up, but he won't stay caught up: the honest population will eventually overtake his chain, and we'll be in an unstable situation where control of the "best" chain will bounce back and forth between them forever....


19

The 51% attack is emergent behavior of the system. It's not because there's a "50%" buried somewhere in the protocol that can just be changed to 60% or 75%. Someone with more hashing power than everyone else combined can, given enough time, always build a longer chain than everyone else.


18

The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions. Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, ...


10

(adding some color) Some discussion I saw suggested that people promoting this believed they only needed to achieve >50% hashpower, which caused them to overestimate the feasibility. Reorging with only slightly over 50% would take weeks-- even months, creating massive disruption if successful, and virtually guaranteeing an effective public initiative to ...


9

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks? Because you can't prove that to nodes that weren't on the network at the time of the attack. Which means that either:...


8

First, a quick clarification: assuming two chains both have valid blocks, it's the chain with the most proof of work that wins, not necessarily the chain with the most blocks. Second, thanks for the psuedocode. It's always nice answering a question written in clear code. The answer is that we want nodes to be able to agree on the best block chain based ...


8

There is a handy chart at https://en.bitcoin.it/wiki/Mining_hardware_comparison. If we assume that it is complete, and that the figures listed there are accurate (I have not verified them), and that the attacker must buy the hardware, then the most economical device is the Antminer S5+, which produces 7.7 TH/s (7.7e12 H/s) and costs US$2300. It draws 3.4 ...


8

As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization. ...


7

Conceptually it isn't difficult to understand conflicts of interests (COI) principles. If a pool has over 50% of the computing power required to demonstrate adequate "proof of work" to add entries to the Blockchain Ledger, this absolute centralized power will eventually "absolutely corrupt". That centralized pool could be used to change the history of ...


7

There are two assumptions in your question that aren't completely correct. 1) Each node would then require 68 minutes to find a proof of work (trying 2^52 hashes). The process of finding a new block is not a linear task of work that needs to be accumulated. Rather it is a random process. Instead of a pile of work you are going through that has a fixed size,...


7

An attacker has a hard time changing the past An attacker has very limited influence to change old blocks, because he has to replace all blocks that confirm the event he wants to change and keep up with the new ones that the network is still creating. Example: Say, Eve achieved to control 51% of the hash rate and wants to unconfirm a transaction from 6 ...


7

Because miners do not actually own/ or have access to the bitcoins which are being spent in a transaction. They simply choose a number of transactions which have valid signatures, and put them together with the hash they created/solved, thus creating a valid block. See https://en.bitcoin.it/wiki/Block_hashing_algorithm for more information. The person that ...


6

Bitcoin has a huge incentive system to discourage a 51% attack. Bitcoin mining with CPUs is impractical. You have to use dedicated hardware that can only be used to mine Bitcoin and other coins that use the exact same algorithm. So to acquire enough hashing power to launch a 51% attack on Bitcoin, you can't just rent computing power or buy CPUs. You have to ...


6

This is to impart the need for a higher hash rate than the rest of the (honest) miners. Mining success is probabilistic, however, so this 50% or 51% is an indication of the expected behaviour given an infinite number of attempts. Using the scenario where an attacker tries to build their own chain to eventually replace the original one: If the attacker has ...


5

Generally, no, not until it's too late. A typical 51% attack would look like this: Attacker privately starts mining their own chain, which diverges from the main chain at some block N. Attacker deposits coins to your business, sending them from address A. Call this transaction X. Attacker inserts in his own chain a transaction X' which conflicts with X; ...


5

David Schwartz has a good answer. But to explore a little further, you can roughly think of Bitcoin's proof-of-work system, in the long run, as an election to decide which is the "true" block chain, and hence, which transactions are recognized as having occurred. As it stands, each miner gets voting power in this election proportional to their hash power (...


5

Even if the dynamics are interpreted in the most basic way, it does not lead to this positive feedback, rather it maintains the status quo. If there are miners with stake of 40%, 30% and 30%, they will get 40%, 30% and 30% of the rewards respectively, so the ratios will remain at 40%, 30%, 30%. For example, if they start with 40, 30, 30 BTC, and 10 new ...


5

I think what most people making the 51% attack argument for memory hardness miss is that the base unit is meaningless when you're talking about percentages. Whether your mining algorithm is implemented with ASICs, consumer hardware or well-trained Rhesus monkeys it matters little - to launch a 51% attack you must amass enough ASICs, consumer hardware or ...


5

You could easy manipulate a pool to wreck havoc on other SHA256 coins if you owned it or managed to gain access. You don't even need to be a large pool, some altcoins are really small and vulnerable. It has affected other coins before, where a pool or a large miner created trouble solely by mining a smaller altcoin. Feathercoin hit by massive attack Only ...


5

Because of the cost, specifically the opportunity cost. If a miner has 10% of the BTC hashrate, then if they pointed all of that mining power to BCH, they would still be losing money. With 50% of the hashrate on BCH, they would mine roughly 50% of the blocks in a day, which is 72 blocks. At 12.5 BCH per block,72 * 12.5 = 900 BCH. Convert that to BTC at the ...


5

Yes, miners can censor transactions. A mining pool (or solo miner) can choose to not add a transaction to any blocks that they create. And, of course, this can be done dynamically so that transactions that match whatever arbitrary rules they want can be disallowed. However this only effects one mining pool or miner. Other miners will not necessarily follow ...


4

Maybe. It would require a split in bitcoin users. Those who wanted the change could switch to a new version of the bitcoin software with the code changed to allow it. The problem comes from the fact that it would have to be a voluntary change. Some would want to change, others wouldn't, and this would split the bitcoin community. Any transactions that occur ...


4

'Longer' means 'more total work spent'. You're not going to be working harder than all miners put together are you? Then the only way to get some money is to join the existing miners and work with them. And by doing that you coincidentally enlarge the group of 'honest' miners, making it that much harder for someone else to consider your 'evil' plan.


4

I think you should state exactly what you mean by "51% attack". If by attack you mean double-spending, the original Bitcoin paper by Satoshi outlines that it brings more reward to mine all the blocks for yourself and obtain 100% of the rewards rather than attempt a re-org for the double-sending, which might lose you the rewards and therefore the miners (...


4

When a previously unknown chain fork of at least 7 blocks length is published, how does Bitcoin Core react? It reorganizes to that chain, any transactions that were lost are returned to the nodes mempool. Would Bitcoin Core accept the chain fork if it had the most work? Any valid chain with the most work will be reorganised to. How prominent is the ...


4

Let's assume for a minute that your theory is true, and that actual nodes on the network would not accept this new, valid, and longer block chain. That on itself would be a bug. Maybe it isn't obvious for a 5-block reorganization, but if it was a 2-block deep one (which actually occurs in practice), your argument would be equally true. If there was no means ...


4

The rest of the network, which uses the existing difficulty parameters, will reject the new blocks generated by your modified miners. There will be a longer blockchain, but there will not be a longer valid blockchain according to the established rules.


4

But how exactly the consensus rules are forced? Every single full node enforces them. Internet says that the consensus rules are the rules thet every full node follows. And rejects blocks that do not meet consensus rules "no matter what". Correct. Ok. But. Should ALL of the full nodes accept? Or should MOST of the full nodes accept? Or is there ...


Only top voted, non community-wiki answers of a minimum length are eligible