Jump to: navigation, search A majority attack (usually labeled 51% attack or >50% attack) is an attack on the network.This attack has a chance to work even if the merchant waits for some confirmations, but requires extremely high relative hashrate.The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a double-spending transaction is included instead.After waiting for n confirmations, the merchant sends the product.If the attacker happened to find more than n blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network.If he never manages to do this, the attack fails and the payment to the merchant will go through.The work done mining will also go to waste, as any new bitcoins would be overwritten by the longest chain.The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for.

For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%.If the attacker controls more than half of the network hashrate, this has a probability of 100% to succeed.Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in.A majority attack was more feasible in the past when most transactions were worth significantly more than the block reward and when the network hashrate was much lower and prone to reorganization with the advent of new mining technologies.

A majority attack has never been executed on the Bitcoin network.Attack success probability calculator Double spendingHome Cryptocurrency 51% Attack 51% Attack What is often considered a very large flaw in the design of Bitcoin is that hypothetically, if a single entity contributed the majority of the network’s mining hashrate, they would have full control of the network and would be able to manipulate the public ledger (blockchain) at will.It is an interesting concept because it is theoretically possible; the network is free and open, so if someone were to have enough computational power (which would cost a huge amount by itself), there is no bitcoin authority to stop them from doing so.In the event that such an attack successfully takes place, it is likely confidence in the currency would be lost and it’s value as a currency would decline rapidly."Wait, they’d have complete control of the network?They could do anything?"There’s only a couple things someone with 51% of the network hashrate could do.

They could prevent transactions of their choosing from gaining any confirmations, thus making them invalid, potentially preventing people from sending Bitcoins between addresses.They could also reverse transactions they send during the time they are in control (allowing double spend transactions), and they could potentially prevent other miners from finding any blocks for a short period of time.bitcoin armory sourceThat’s really about it – enough power to cause some serious mayhem (as that’s all stuff that isn’t supposed to be able to happen) but nothing that would seriously cripple the network – at least not immediately.bcn to bitcoinThey couldn’t reverse transactions from long ago, create new coins out of thin air (besides through regular mining), or steal coins from other people’s wallets.samsung s5 bitcoin

In reality a 51% attack is feasible – especially with the rise of mining pools (groups of people mining together as a single unit).However the potential damage one could cause is small – though enough that it cause a panic that would seriously threaten bitcoin’s use as an online currency.bitcoin trillion dollar market capAt current network mining difficulty levels, not even large-scale governments could easily mount a 51% attack.king of bitcoin ebookJump to: , Contents 1 2 3 4 The wallet is stored unencrypted, by default, and thus becomes a valuable target for theft.bitcoin asic hardware ukRecent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.ethereal gem wikipedia

An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.bitcoin mining in uaeAn initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause) the creation of a new wallet with new addresses, and the sending of existing sums to them.bitcoin mining software nvidiaBacked-up copies of the original wallet with the original password would then be empty, should they be compromised.On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and - intially at least - the new wallet is no longer backed up.

On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.Tracing a coin's history can be used to connect identities to addresses.An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes.Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.This state can be exploited in (at least) the following ways: Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0).Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.Looking for suspiciously low network hash-rates may help prevent the second one.

Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which suggests you originated it).Bitcoin-QT has good Tor integration which closes this attack vector if used.Sending lots of data to a node may make it so busy it cannot process normal Bitcoin transactions.Bitcoin has some denial-of-service prevention built-in, but is likely still vulnerable to more sophisticated denial-of-service attacks.These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0: These are protocol rules built to prevent DoS: These are the Satoshi client protections added in version 0.8.0: Satoshi client does not directly limit peer bandwidth nor CPU usage.See Timejacking for a description of this attack.It can be fixed by changing how nodes calculate the current time.It is illegal in some countries to possess/distribute certain kinds of data.Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems.

However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts.Various ideas have been proposed to further limit datastorage in the UTXO set but are not currently being seriously considered for deployment.It's possible but unlikely that a newly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every node to upgrade in a short time period.For example, a single malformed message tailored to exploit a specific vulnerability, when spread from node to node, could cause the whole network to shutdown in a few hours.Bugs that break user anonymity, on the contrary, have been found, since the pseudo-anonymity property of Bitcoin has been analyzed less.Starting from version 0.7.0, Bitcoin client can be considered a mature project.The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts.

Also Bitcoin Satoshi client has passed the test of being on-line for more than 3 years, without a single vulnerability being exploited in the wild.See Common Vulnerabilities and Exposures for a detailed list of vulnerabilities detected and fixed.Energy consumption for mining has a high correlation with bitcoin value (exchange rate).Because variable costs of mining are dominated by electricity price, the economic equilibrium for the mining rate is reached when global electricity costs for mining approximate the value of mining reward plus transaction fees.So the higher the value of one bitcoin, the higher the value of mining rewards and transaction fees, the higher the energy consumption of the bitcoin network in the long run.SHA-256 and ECDSA are considered very strong currently, but they might be broken in the far future.If that happens, Bitcoin can shift to a stronger algorithm.Bitcoin can easily scale beyond the level of traffic VISA sees globally today.See the discussion on the scalability page for more information.

If there is even a "trickle" of a connection between two sides of a segmented network, things should still work perfectly.When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool -- they'll start over at 0/unconfirmed, but they'll still be valid.No mature transactions will be lost unless the segmentation persists for longer than ~120 blocks.Then generations will start to mature, and any transactions based on those generations will become invalid when recombined with the longer chain.The IP addresses of most users are totally public.You can use Tor to hide this, but the network won't work if everyone does this.Bitcoin requires that some country is still free.Nodes that generate blocks can choose not to include a transaction in their blocks.When this happens, the transaction remains "active" and can be included in a later block.Two things discourage this: An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions.

This allows him to: Note that the above limitations only apply to the perspective of Bitcoin as seen by full nodes.Some lightweight nodes work by trusting miners absolutely; from the perspective of Bitcoin as seen by lightweight nodes, miners can steal BTC, etc. This is one of the reasons why lightweight nodes are less secure than full nodes.With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success.For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate [1].It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go.As above, changing historical blocks only allows you to exclude and change the ordering of transactions.If miners rewrite historical blocks too far back, then full nodes with pruning enabled will be unable to continue, and will shut down; the network situation would then probably need to be untangled manually (eg.

by updating the software to reject this chain even though it is longer).Since this attack doesn't permit all that much power over the network, it is expected that rational miners will not attempt it.A profit-seeking miner should always gain more by just following the rules, and even someone trying to destroy the system might find other attacks more attractive.Probably the most likely scenario where this attack would be employed would be for a government to try to get control over Bitcoin by acquiring a majority of hashing power (either directly or by enforcing rules on private miners within its borders).Then this government could use the transaction-censorship power listed above to do things like: The appropriate response to any long-term attack by miners is a hardfork to change the proof-of-work function.This fires all existing miners, and allows totally new ones to replace them.It is easy to send transactions to yourself repeatedly.If these transactions fill blocks to the maximum size (1MB), other transactions would be delayed until the next block.

This is made expensive by the fees that would be required after the 50KB of free transactions per block are exhausted.An attacker will eventually eliminate free transactions, but Bitcoin fees will always be low because raising fees above 0.01 BTC per KB would require spending transaction fees.An attacker will eventually run out of money.Even if an attacker wants to waste money, transactions are further prioritized by the time since the coins were last spent, so attacks spending the same coins repeatedly are less effective.Named for Hal Finney, who first described this variation of a double-spend attack involving accepting 0-confirmation transactions.Accepting 0-confirmation large-value transactions is problematic; accepting them for low-value transactions (after waiting several seconds to detect an ordinary double-spend attempt) is probably safe.Any rival client must follow Bitcoin's rules or else all current Bitcoin clients will ignore it.You'd have to actually get people to use your client.

A better client that pretends to follow the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to gain widespread adoption.At that point, its author could use his exception and go largely unnoticed.Bitcoin has 2.1 quadrillion raw units, making up 8 decimals of BTC precision, so the entire network could potentially operate on much less than the full quantity of Bitcoins.If deflation gets to the point where transactions of more than 10 BTC are unheard of, clients can just switch to another unit so that, for example, it shows 10 mBTC rather than 0.01 BTC.The maximum number of raw units might not be enough if the entire world starts using BTC, but it would not be too difficult to increase precision in that case.The transaction format and version number would be scheduled to change at some particular block number after a year or two, and everyone would have to update by then.Generating an address doesn't touch the network at all.

You'd only be wasting your CPU resources and disk space.Also, a collision is highly unlikely.Keys are 256 bit in length and are hashed in a 160 bit address.(2^160thpower) Divide it by the world population and you have about 215,000,000,000,000,000,000,000,000,000,000,000,000 addresses per capita.(2.15x 10^38)[1] If everyone began with identical blocks and started their nonce at 1 and incremented, the fastest machine would always win.However, each block contains a new, random public key known only to you in the list of transactions.The 256-bit "Merkle tree" hash of this is part of the block header.So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).Using unmodified Bitcoin code, an attacker could segment himself from the main network and generate a long block chain with a lower difficulty than the real network.These blocks would be totally valid for his network.However, it would be impossible to combine the two networks (and the "false" chain would be destroyed in the process).