Topic: bitcoin weaknesses, can anyone explain? (Read 1006 times)
Every technology is going to have strengths and weaknesses. Bitcoin is new and the first of its kind. None of these weaknesses are sufficient to make bitcoins unsuitable for the purposes they are typically used, but bitcoins are not suitable for every imaginable purpose.
What would you like explained?
Hello, i have read on bitcoin wiki in technical page, bitcoin weaknesses:
problem:
can be a problem:
problem:
Quote
Wallet Vulnerable To Theft
The wallet is stored unencrypted, thus it becomes a valuable target for theft. That this is a problem was evidenced by the negative publicity following Allinvain's June 2011 claim that his wallet was stolen. Wallet encryption is slated to be merged into the 0.4 release. Patches are being developed also for other implementations.
Forcing clock drift against a target node
See Timejacking for a description of this attack. It can be fixed by changing how nodes calculate the current time.
Tracing a coin's history
Tracing a coin's history can be used to connect identities to addresses. More info.
Cancer nodes
It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.
For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways:
The attacker can refuse 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 0 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 easy with a timing attack if you're connected to several of the attacker's nodes 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 probably already unable to accept incoming connections.
Looking for suspiciously low network hash-rates may help prevent the second one.
No authentication for IP transfers
Since there's no authentication when sending to an IP address (as opposed to a Bitcoin address), executing a man-in-the-middle attack and stealing the sent BitCoins is trivial. This attack is downright likely if you're using Tor.
Packet sniffing
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which means that it's yours). This would be made more difficult (but not impossible) if node-to-node encryption was used.
Denial of Service (DoS) attacks
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 (it will drop connections to peers that send it too much data too quickly), but is likely still vulnerable to more sophisticated denial-of-service attacks.
The wallet is stored unencrypted, thus it becomes a valuable target for theft. That this is a problem was evidenced by the negative publicity following Allinvain's June 2011 claim that his wallet was stolen. Wallet encryption is slated to be merged into the 0.4 release. Patches are being developed also for other implementations.
Forcing clock drift against a target node
See Timejacking for a description of this attack. It can be fixed by changing how nodes calculate the current time.
Tracing a coin's history
Tracing a coin's history can be used to connect identities to addresses. More info.
Cancer nodes
It's trivial for an attacker to fill the network with clients controlled by him. This might be helpful in the execution of other attacks.
For example, an attacker might connect 100,000 IP addresses to the IRC bootstrap channel. You would then be very likely to connect only to attacker nodes. This state can be exploited in (at least) the following ways:
The attacker can refuse 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 0 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 easy with a timing attack if you're connected to several of the attacker's nodes 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 probably already unable to accept incoming connections.
Looking for suspiciously low network hash-rates may help prevent the second one.
No authentication for IP transfers
Since there's no authentication when sending to an IP address (as opposed to a Bitcoin address), executing a man-in-the-middle attack and stealing the sent BitCoins is trivial. This attack is downright likely if you're using Tor.
Packet sniffing
Someone who can see all of your Internet traffic can easily see when you send a transaction that you didn't receive (which means that it's yours). This would be made more difficult (but not impossible) if node-to-node encryption was used.
Denial of Service (DoS) attacks
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 (it will drop connections to peers that send it too much data too quickly), but is likely still vulnerable to more sophisticated denial-of-service attacks.
can be a problem:
Quote
Breaking the cryptography
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. More info.
Scalability
BitCoin can easily 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 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. 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.
Dropping transactions
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:
Nodes only hash a fixed-size header, so there is no speed advantage to dropping 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 allows him to:
Reverse transactions that he sends while he's in control
Prevent some or all transactions from gaining any confirmations
Prevent some or all other generators from getting any generations
The attacker can't:
Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him
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. It's impossible to change blocks created before the last checkpoint.
Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.
Spamming transactions
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.
The "Finney" attack
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.
Rival/malicious client code
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.
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. More info.
Scalability
BitCoin can easily 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 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. 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.
Dropping transactions
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:
Nodes only hash a fixed-size header, so there is no speed advantage to dropping 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 allows him to:
Reverse transactions that he sends while he's in control
Prevent some or all transactions from gaining any confirmations
Prevent some or all other generators from getting any generations
The attacker can't:
Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him
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. It's impossible to change blocks created before the last checkpoint.
Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.
Spamming transactions
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.
The "Finney" attack
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.
Rival/malicious client code
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.
Jump to: