Weaknesses

Might be a problem

The wallet is stored unencrypted, by default, and thus becomes a valuable target for theft. Latest releases of the Bitcoin client now supports encryption to protect the wallet data, tho’ the user must opt-in.

An old copy of a wallet with its old password is often lightly 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 ‘switch the password on your wallet’ should mean following password compromise.

An initial solution is to mandate (either in code or as voiced policy) that switching a wallet’s password causes (or asks the user to cause) the creation of a fresh wallet with fresh addresses, and the sending of existing sums to them. Backed-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 fresh 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 ruin them.

Tracing a coin’s history

Tracing a coin’s history can be used to connect identities to addresses. More info.

Sybil attack

An attacker can attempt to pack the network with clients managed by him, you would then be very likely to connect only to attacker knots. Albeit Bitcoin never uses a count of knots for anything downright isolating a knot from the fair network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

  • The attacker can turn down to relay blocks and transactions from everyone, disconnecting you from the network.
  • The attacker can relay only blocks that he creates, putting you on a separate network. You’re then open to double-spending attacks.
  • If you rely on transactions with zero confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
  • Low-latency encryption/anonymization of Bitcoin’s transmissions (With Tor, JAP, etc.) can be defeated relatively effortless with a timing attack if you’re connected to several of the attacker’s knots and the attacker is watching your transmissions at your ISP.

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 most likely already incapable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the 2nd one.

Packet sniffing

Someone who can see all of your Internet traffic can lightly 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.

Denial of Service (DoS) attacks

Sending lots of data to a knot 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:

  1. Does not forward orphan transactions/blocks
  2. Does not forward double-spend transactions
  3. Does not forward the same block, transaction or alert twice to the same peer.
  4. Continuous rate-limit of free transactions to mitigate ‘penny-flooding’
  5. Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to obey with the rules.
  6. Bans IP addresses that misbehave for a time lapse (24 hours default)
  7. Thresholds the number of stored orphan transactions (10000 by default)
  8. Uses a signature cache to prevent attacks that attempt to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)
  9. Thresholds the number of stored signatures in the signature cache (50000 signatures by default)
  10. Attempts to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.
  11. Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
  12. In orphan/signature caches, when removing an item, evicts a random entry.
  13. Data structures are specially chosen to avoid loops in which the number of iterations can be managed by an attacker that result in exponential complexity.
  14. Overlooks big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
  15. In RPC: Only sends a HTTP four hundred three response if it’s not using SSL to prevent a DoS during the SSL handshake.
  16. In RPC: Sleeps some time if authorization fails to deter brute-forcing brief passwords.
  17. In GUI: Thresholds URI length to prevent a DoS against the QR-Code dialog
  18. Considers non-standard signature scripts with size greater than five hundred bytes.
  19. Considers non-standard signature scripts that contain operations that are not PUSHs.
  20. Does not forward nor process non-standard transactions

These are protocol rules built to prevent DoS:

  1. Restricts the block size to one megabyte.
  2. Restricts the maximum number of signature checks a transaction input may request
  3. Boundaries the size of each script (up to ten thousand bytes)
  4. Thresholds the size of each value shoved while evaluating a a script (up to five hundred twenty bytes)
  5. Boundaries the number of expensive operations in a script (up to two hundred one operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an extra operation.
  6. Boundaries the number of key arguments OP_CHECKMULTISIG can use (up to twenty keys)
  7. Boundaries the number of the stack elements that can be stored at the same time (up to one thousand elements, in standard and alt stacks together)
  8. Boundaries the number of signature checks a block may request (up to twenty thousand checks)

These are the Satoshi client protections added in version 0.8.0:

  1. Transactions greater than one hundred Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).
  2. Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.
  3. When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/index.php?topic=144122.0) DoS attack)

Satoshi client does not directly limit peer bandwidth nor CPU usage.

Forcing clock drift against a target knot

See Timejacking for a description of this attack. It can be immobile by switching how knots calculate the current time.

Illegal content in the block chain

It is illegal in some countries to wield/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and utter Bitcoin knots must normally have a copy of all unspent transactions, this could cause legal problems. However, Local knot policy generally doesn’t permit arbitrary data (transactions attempting to embed data re non-standard), but steganographic embedding can still be used tho’ this generally boundaries storage to petite amounts. Various ideas have been proposed to further limit datastorage in the UTXO set but are not presently being earnestly considered for deployment.

Security Vulnerabilities and bugs

It’s possible but unlikely that a freshly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every knot to upgrade in a brief time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from knot to knot, could cause the entire 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. Embarking 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 three years, without a single vulnerability being exploited in the wild. See Common Vulnerabilities and Exposures for a detailed list of vulnerabilities detected and motionless.

Energy Consumption

Energy consumption for mining has a high correlation with bitcoin value (exchange rate). Because variable costs of mining are predominated by electric current price, the economic equilibrium for the mining rate is reached when global tens unit costs for mining approximate the value of mining prize plus transaction fees.

So the higher the value of one bitcoin, the higher the value of mining prizes and transaction fees, the higher the energy consumption of the bitcoin network in the long run.

  • more efficient mining gear does not reduce energy use of the bitcoin network. It will only raise the network difficulty
  • cheaper energy linearly increases mining energy use of the bitcoin network
  • the same conclusions apply to all proof of work based currencies.

Most likely not a problem

Cracking the cryptography

SHA-256 and ECDSA are considered very strong presently, but they might be violated in the far future. If that happens, Bitcoin can shift to a stronger algorithm. More info.

Scalability

Bitcoin can lightly scale beyond the level of traffic VISA sees globally today. See the discussion on the scalability page for more information.

Segmentation

If there is even a “trickle” of a connection inbetween two sides of a segmented network, things should still work flawlessly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool — they’ll begin 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 commence to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. More info.

Attacking all users

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.

Ripping off transactions

Knots 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:

  • Knots only hash a fixed-size header, so there is no speed advantage to pulling down transactions.
  • Satoshi has communicated that he will write code to stop this kind of thing if it becomes a problem.

Attacker has a lot of computing power

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 permits him to:

  • Switch sides transactions that he sends while he’s in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
  • Prevent some or all transactions from gaining any confirmations
  • Prevent some or all other miners from mining any valid blocks

The attacker can’t:

  • Switch sides other people’s transactions without their cooperation
  • Prevent transactions from being sent at all (they’ll showcase as 0/unconfirmed)
  • Switch the number of coins generated per block
  • Create coins out of skinny air
  • Send coins that never belonged to him

Note that the above limitations only apply to the perspective of Bitcoin as seen by utter knots. Some lightweight knots work by trusting miners absolutely; from the perspective of Bitcoin as seen by lightweight knots, miners can steal BTC, etc. This is one of the reasons why lightweight knots are less secure than utter knots.

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 switch historical blocks, and it becomes exponentially more difficult the further back you go. As above, switching historical blocks only permits you to exclude and switch the ordering of transactions. If miners rewrite historical blocks too far back, then total knots with pruning enabled will be incapable to proceed, and will shut down; the network situation would then very likely need to be untangled by hand (eg. by updating the software to reject this chain even however 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 build up more by just following the rules, and even someone attempting to demolish the system might find other attacks more attractive. Very likely the most likely screenplay where this attack would be employed would be for a government to attempt 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:

  • Prevent any transactions spending “stolen” coins, effectively ruining those coins. If the coins clearly are stolen, then there is a risk that this activity will be accepted by the Bitcoin community, but this would set a very hurting precedent. If it becomes possible for coins to be blacklisted in this way, then it is a slimy slope toward blacklisting of other “suspicious” coins.
  • Prevent all transactions from unknown people, so everyone has to register with the government in order to transact.

The suitable response to any long-term attack by miners is a hardfork to switch the proof-of-work function. This fires all existing miners, and permits totally fresh ones to substitute them.

Spamming transactions

It is effortless to send transactions to yourself repeatedly. If these transactions pack 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 tired. 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.

The Finney attack

Named for Hal Finney, who very 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 most likely safe.

Rival/malicious client code

Any rival client must go after Bitcoin’s rules or else all current Bitcoin clients will overlook it. You’d have to actually get people to use your client. A better client that pretends to go after the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to build up widespread adoption. At that point, its author could use his exception and go largely unnoticed.

Certainly not a problem

Coin destruction

Bitcoin has Two.1 quadrillion raw units, making up eight decimals of BTC precision, so the entire network could potentially operate on much less than the total quantity of Bitcoins. If deflation gets to the point where transactions of more than ten BTC are unheard of, clients can just switch to another unit so that, for example, it shows ten 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 switch at some particular block number after a year or two, and everyone would have to update by then.

Generating tons of addresses

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 very unlikely.

Keys are two hundred fifty six bit in length and are hashed in a one hundred sixty bit address.(2^160th power) 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.(Two.15 x 10^38)[1]

Everyone calculates at the same rate

If everyone began with identical blocks and began their nonce at one and incremented, the fastest machine would always win. However, each block contains a fresh, 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 commences with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).

Generate “valid” blocks with a lower difficulty than normal

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 unlikely to combine the two networks (and the “false” chain would be demolished in the process).

“Block chain length” is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win.

Weaknesses – Bitcoin Wiki

Weaknesses

Might be a problem

The wallet is stored unencrypted, by default, and thus becomes a valuable target for theft. Latest releases of the Bitcoin client now supports encryption to protect the wallet data, tho’ the user must opt-in.

An old copy of a wallet with its old password is often lightly 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 ‘switch the password on your wallet’ should mean following password compromise.

An initial solution is to mandate (either in code or as voiced policy) that switching a wallet’s password causes (or asks the user to cause) the creation of a fresh wallet with fresh addresses, and the sending of existing sums to them. Backed-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 fresh 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 ruin them.

Tracing a coin’s history

Tracing a coin’s history can be used to connect identities to addresses. More info.

Sybil attack

An attacker can attempt to pack the network with clients managed by him, you would then be very likely to connect only to attacker knots. Albeit Bitcoin never uses a count of knots for anything totally isolating a knot from the fair network can be helpful in the execution of other attacks.

This state can be exploited in (at least) the following ways:

  • The attacker can turn down to relay blocks and transactions from everyone, disconnecting you from the network.
  • The attacker can relay only blocks that he creates, putting you on a separate network. You’re then open to double-spending attacks.
  • If you rely on transactions with zero confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.
  • Low-latency encryption/anonymization of Bitcoin’s transmissions (With Tor, JAP, etc.) can be defeated relatively effortless with a timing attack if you’re connected to several of the attacker’s knots and the attacker is watching your transmissions at your ISP.

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 very likely already incapable to accept incoming connections.

Looking for suspiciously low network hash-rates may help prevent the 2nd one.

Packet sniffing

Someone who can see all of your Internet traffic can lightly 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.

Denial of Service (DoS) attacks

Sending lots of data to a knot 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:

  1. Does not forward orphan transactions/blocks
  2. Does not forward double-spend transactions
  3. Does not forward the same block, transaction or alert twice to the same peer.
  4. Continuous rate-limit of free transactions to mitigate ‘penny-flooding’
  5. Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to serve with the rules.
  6. Bans IP addresses that misbehave for a time lapse (24 hours default)
  7. Thresholds the number of stored orphan transactions (10000 by default)
  8. Uses a signature cache to prevent attacks that attempt to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)
  9. Thresholds the number of stored signatures in the signature cache (50000 signatures by default)
  10. Attempts to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.
  11. Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
  12. In orphan/signature caches, when removing an item, evicts a random entry.
  13. Data structures are specially chosen to avoid loops in which the number of iterations can be managed by an attacker that result in exponential complexity.
  14. Overlooks big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
  15. In RPC: Only sends a HTTP four hundred three response if it’s not using SSL to prevent a DoS during the SSL handshake.
  16. In RPC: Sleeps some time if authorization fails to deter brute-forcing brief passwords.
  17. In GUI: Boundaries URI length to prevent a DoS against the QR-Code dialog
  18. Considers non-standard signature scripts with size greater than five hundred bytes.
  19. Considers non-standard signature scripts that contain operations that are not PUSHs.
  20. Does not forward nor process non-standard transactions

These are protocol rules built to prevent DoS:

  1. Restricts the block size to one megabyte.
  2. Restricts the maximum number of signature checks a transaction input may request
  3. Thresholds the size of each script (up to ten thousand bytes)
  4. Thresholds the size of each value shoved while evaluating a a script (up to five hundred twenty bytes)
  5. Thresholds the number of expensive operations in a script (up to two hundred one operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an extra operation.
  6. Boundaries the number of key arguments OP_CHECKMULTISIG can use (up to twenty keys)
  7. Boundaries the number of the stack elements that can be stored at the same time (up to one thousand elements, in standard and alt stacks together)
  8. Boundaries the number of signature checks a block may request (up to twenty thousand checks)

These are the Satoshi client protections added in version 0.8.0:

  1. Transactions greater than one hundred Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).
  2. Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.
  3. When processing a transaction, before fetching transaction inputs from disk to memory, the client checks that all the inputs are unspent (protects from the Continuous Hard Disk Seek/Read Activity (https://bitcointalk.org/index.php?topic=144122.0) DoS attack)

Satoshi client does not directly limit peer bandwidth nor CPU usage.

Forcing clock drift against a target knot

See Timejacking for a description of this attack. It can be immovable by switching how knots calculate the current time.

Illegal content in the block chain

It is illegal in some countries to wield/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and utter Bitcoin knots must normally have a copy of all unspent transactions, this could cause legal problems. However, Local knot policy generally doesn’t permit arbitrary data (transactions attempting to embed data re non-standard), but steganographic embedding can still be used however this generally boundaries storage to puny amounts. Various ideas have been proposed to further limit datastorage in the UTXO set but are not presently being gravely considered for deployment.

Security Vulnerabilities and bugs

It’s possible but unlikely that a freshly discovered bug or security vulnerability in the standard client could lead to a block chain split, or the need for every knot to upgrade in a brief time period. For example, a single malformed message tailored to exploit a specific vulnerability, when spread from knot to knot, could cause the entire 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. Embarking 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 three years, without a single vulnerability being exploited in the wild. See Common Vulnerabilities and Exposures for a detailed list of vulnerabilities detected and motionless.

Energy Consumption

Energy consumption for mining has a high correlation with bitcoin value (exchange rate). Because variable costs of mining are predominated by electric current price, the economic equilibrium for the mining rate is reached when global electrical play costs for mining approximate the value of mining prize plus transaction fees.

So the higher the value of one bitcoin, the higher the value of mining prizes and transaction fees, the higher the energy consumption of the bitcoin network in the long run.

  • more efficient mining gear does not reduce energy use of the bitcoin network. It will only raise the network difficulty
  • cheaper energy linearly increases mining energy use of the bitcoin network
  • the same conclusions apply to all proof of work based currencies.

Very likely not a problem

Violating the cryptography

SHA-256 and ECDSA are considered very strong presently, but they might be cracked in the far future. If that happens, Bitcoin can shift to a stronger algorithm. More info.

Scalability

Bitcoin can lightly scale beyond the level of traffic VISA sees globally today. See the discussion on the scalability page for more information.

Segmentation

If there is even a “trickle” of a connection inbetween two sides of a segmented network, things should still work flawlessly. When block chains are combined, all of the non-generation transactions in the shorter chain are re-added to the transaction pool — they’ll embark 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 commence to mature, and any transactions based on those generations will become invalid when recombined with the longer chain. More info.

Attacking all users

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.

Pulling down transactions

Knots 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:

  • Knots only hash a fixed-size header, so there is no speed advantage to pulling down transactions.
  • Satoshi has communicated that he will write code to stop this kind of thing if it becomes a problem.

Attacker has a lot of computing power

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 permits him to:

  • Switch sides transactions that he sends while he’s in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
  • Prevent some or all transactions from gaining any confirmations
  • Prevent some or all other miners from mining any valid blocks

The attacker can’t:

  • Switch roles other people’s transactions without their cooperation
  • Prevent transactions from being sent at all (they’ll demonstrate as 0/unconfirmed)
  • Switch the number of coins generated per block
  • Create coins out of skinny air
  • Send coins that never belonged to him

Note that the above limitations only apply to the perspective of Bitcoin as seen by utter knots. Some lightweight knots work by trusting miners absolutely; from the perspective of Bitcoin as seen by lightweight knots, miners can steal BTC, etc. This is one of the reasons why lightweight knots are less secure than total knots.

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 switch historical blocks, and it becomes exponentially more difficult the further back you go. As above, switching historical blocks only permits you to exclude and switch the ordering of transactions. If miners rewrite historical blocks too far back, then utter knots with pruning enabled will be incapable to proceed, and will shut down; the network situation would then most likely need to be untangled by hand (eg. by updating the software to reject this chain even however 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 build up more by just following the rules, and even someone attempting to ruin the system might find other attacks more attractive. Most likely the most likely script where this attack would be employed would be for a government to attempt 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:

  • Prevent any transactions spending “stolen” coins, effectively demolishing those coins. If the coins clearly are stolen, then there is a risk that this activity will be accepted by the Bitcoin community, but this would set a very hurting precedent. If it becomes possible for coins to be blacklisted in this way, then it is a greasy slope toward blacklisting of other “suspicious” coins.
  • Prevent all transactions from unknown people, so everyone has to register with the government in order to transact.

The suitable response to any long-term attack by miners is a hardfork to switch the proof-of-work function. This fires all existing miners, and permits totally fresh ones to substitute them.

Spamming transactions

It is effortless to send transactions to yourself repeatedly. If these transactions pack 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 weakened. 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.

The Finney attack

Named for Hal Finney, who very 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 most likely safe.

Rival/malicious client code

Any rival client must go after Bitcoin’s rules or else all current Bitcoin clients will disregard it. You’d have to actually get people to use your client. A better client that pretends to go after the same rules, but with an exception known only to the author (possibly by making it closed source), might conceivably be able to build up widespread adoption. At that point, its author could use his exception and go largely unnoticed.

Undoubtedly not a problem

Coin destruction

Bitcoin has Two.1 quadrillion raw units, making up eight decimals of BTC precision, so the entire network could potentially operate on much less than the total quantity of Bitcoins. If deflation gets to the point where transactions of more than ten BTC are unheard of, clients can just switch to another unit so that, for example, it shows ten 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 switch at some particular block number after a year or two, and everyone would have to update by then.

Generating tons of addresses

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 very unlikely.

Keys are two hundred fifty six bit in length and are hashed in a one hundred sixty bit address.(2^160th power) 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.(Two.15 x 10^38)[1]

Everyone calculates at the same rate

If everyone began with identical blocks and began their nonce at one and incremented, the fastest machine would always win. However, each block contains a fresh, 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 starts with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).

Generate “valid” blocks with a lower difficulty than normal

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 unlikely to combine the two networks (and the “false” chain would be ruined in the process).

“Block chain length” is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win.

Related video:

admin_en | 1@1.com

Related Posts

I Threw Away $7.6 Million In Bitcoin Five years ago, I threw away a hard drive. An utterly generic 250GB portable hard drive, already a few years old, with a duo of dings and scrapes in its shell and with the beginnings of an audible click that would have eventually killed it. It had a […]

How to Price a Digital Currency? Empirical Insights on the Influence of Media Coverage on the Bitcoin Bubble Digital currencies are gaining more and more attention against the backdrop of latest events triggered by the ongoing economic crisis. While digital currencies face enhancing popularity, the currencies’ prices are free floating and subject to high volatility […]

How much does it cost to make an app like Bitcoin Wallet We’ve already written a few articles about the cost of creating apps similar to Instagram, Yelp, Grindr, Shazam , and others. However, this one will be slightly different as we’ll describe three apps like B itcoin W allet at the same time. If […]

Leave a Reply

Your email address will not be published. Required fields are marked *