https://en.bitcoin.it/w/api.php?action=feedcontributions&feedformat=atom&user=Sergio+Demian+Lerner 2026-06-03T14:07:50Z User contributions MediaWiki 1.43.8 https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=36556 2013-04-01T13:53:51Z

<p>Sergio Demian Lerner: /* Denial of Service (DoS) attacks */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> # Considers non-standard signature scripts with size greater than 500 bytes.<br /> # Considers non-standard signature scripts that contain operations that are not PUSHs.<br /> # Does not forward nor process non-standard transactions<br /> <br /> These are protocol rules built to prevent DoS:<br /> <br /> # Restricts the block size to 1 megabyte.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Limits the size of each script (up to 10000 bytes)<br /> # Limits the size of each value pushed while evaluating a a script (up to 520 bytes)<br /> # Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.<br /> # Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)<br /> # Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)<br /> # Limits the number of signature checks a block may request (up to 20000 checks)<br /> <br /> These are the Satoshi client protections added in version 0.8.0: <br /> <br /> # Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).<br /> # Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.<br /> # 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)<br /> <br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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.<br /> 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=36555 2013-04-01T13:20:38Z

<p>Sergio Demian Lerner: /* Denial of Service (DoS) attacks */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> # Considers non-standard signature scripts with size greater than 500 bytes.<br /> # Considers non-standard signature scripts that contain operations that are not PUSHs.<br /> # Does not forward nor process non-standard transactions<br /> <br /> These are protocol rules built to prevent DoS:<br /> <br /> # Restricts the block size to 1 megabyte.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Limits the size of each value pushed while evaluating a a script (up to 520 bytes)<br /> # Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.<br /> # Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)<br /> # Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)<br /> # Limits the number of signature checks a block may request (up to 20000 checks)<br /> <br /> These are the Satoshi client protections added in version 0.8.0: <br /> <br /> # Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).<br /> # Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.<br /> # 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)<br /> <br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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.<br /> 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=36554 2013-04-01T13:10:07Z

<p>Sergio Demian Lerner: /* Denial of Service (DoS) attacks */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> # Limits the size of each value pushed while evaluating a a script (up to 520 bytes)<br /> # Limits the number of expensive operations in a script (up to 201 operations). All but pushs are considered expensive. Also each key argument of signature checking in multi-signature checking (OP_CHECKMULTISIG) is considered an additional operation.<br /> # Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)<br /> # Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)<br /> <br /> <br /> These are the Satoshi client protections added in version 0.8.0: <br /> <br /> <br /> # Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).<br /> # Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.<br /> # 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)<br /> <br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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.<br /> 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=CVE-2013-2293&diff=35888 2013-03-05T21:01:32Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== New DoS vulnerability by Forcing Continuous Hard Disk Seek/Read Activity ==<br /> <br /> Private Release Date: 08-JAN-2013&lt;br /&gt;<br /> Public Release Date: 14-FEB-2013&lt;br /&gt;<br /> <br /> <br /> == Systems Affected ==<br /> <br /> * Satoshi Bitcoin Client (Bitcoin-Qt, bitcoind)<br /> * All Bitcoin clients that mimic the behavior related to transaction validation of Satoshi client versions prior 0.8.0<br /> <br /> == Affected Versions ==<br /> <br /> * Bitcoin version 0.7.2 released 2012-12-14<br /> * Bitcoin version 0.7.1 released 2012-10-19<br /> * Bitcoin version 0.7.0 released 2012-09-17<br /> * Bitcoin version 0.6.3 released 2012-06-25<br /> * Bitcoin version 0.6.2 released 2012-05-08<br /> * Bitcoin version 0.6.1 released 2012-05-04<br /> * Bitcoin version 0.6.0 released 2012-03-30<br /> * Bitcoin version 0.5.3.1 released 2012-03-16<br /> * Bitcoin version 0.5.3 released 2012-03-14<br /> * Bitcoin version 0.5.2 released 2012-01-09<br /> * Bitcoin version 0.5.1 released 2011-12-15<br /> * Bitcoin version 0.5.0 released 2011-11-21<br /> * Bitcoin version 0.4.0 released 2011-09-23<br /> * Bitcoin version 0.3.24 released 2011-07-08<br /> * Bitcoin version 0.3.23 released 2011-06-14<br /> * Bitcoin version 0.3.22 released 2011-06-05<br /> * Bitcoin version 0.3.21 released 2011-04-27<br /> <br /> <br /> == Overview ==<br /> <br /> Transaction processing has two stages in Satoshi Bitcoin client. In the first stage, transaction inputs are fetched.<br /> This is done by bringing to RAM the transactions that contains the outputs referred by the inputs.<br /> In the second stage, previous outputs are verified to be unspent and the related scripts are evaluated.<br /> Since double spends are not considered to be a DoS attempt by the protocol rules, a transaction that refers to previous spent outputs will pass the first processing stage without being discarded. An attacker can therefore construct transactions that, before being discarded in the second stage of processing, require the victim application to seek and read too many parts of the block chain that could be scattered thought the storage files, delaying any other processing.<br /> <br /> == Details ==<br /> <br /> We assume that the whole block chain does not fit in RAM, so each transaction fetch requires a HD seek and read. An average 7200 rpm hard drive<br /> can random seek/read a 1Kb block in a non-cached 2 Gb file in 12 msec. Each prevout of a transaction consumes 44 bytes, with empty sigscripts.<br /> The attacker creates transaction with many inputs an one output. In this way, the other sections of the transaction (output scripts, headers) are amortized and become irrelevant to this analysis.<br /> For an Internet connection of 50 Kbytes/sec bandwidth, sending 45 bytes requires less than 1 msec.<br /> By continuously sending this specially crafted transactions an attacker can block any Bitcoin peer from performing other tasks.<br /> Also the attacker may be able to block 10 peers at the same time, since the relation of 1:10 in required resources.<br /> Note that the attacker does not need to sign the inputs nor to have the full block-chain to perform the attack. He only requires the hashes of all previous transactions, which currently requires only 10876856*32=332 Mbytes of storage.<br /> <br /> Version 0.8.0 of the Satoshi client stores only unspent prevouts in memory and can abort processing right after a spent prevout is referred by a transaction.<br /> <br /> == Possible Attack Scenarios ==<br /> <br /> 1. Because of the small resources required to mount the attack, it could be performed by botnets to massively attack the Bitcoin network.<br /> <br /> 2. The attack can be used against miners to prevent them from sending blocks. Nevertheless, currently big miners are only connected to there own front-line of Bitcoin nodes to preven such attacks.<br /> <br /> 3. By using many nodes at once, an attacker may try to create a barrier that splits the network in unconnected components, in order to carry another kind of attack.<br /> <br /> == Not-a-problem variations ==<br /> <br /> 1. A valid 1M transaction could be constructed to reference more than 22K unique input transactions. In theory that transaction would take more than 5 minutes to be verified. Nevertheless the attack is unpractical for two reasons:&lt;br /&gt;<br /> a. The attacker should have to own those 22K transactions.&lt;br /&gt;<br /> b. Those 22K transactions should have to be scattered thought the blockchain to force HD seeking activity. If they were created in a limited period of time, they would end up confined in a limited portion of the block chain file. The result would be that the hard disk cache will help to reduce the read latency and so attack effectiveness will be reduced. Nevertheless version 0.8.0 of the Satoshi client considers transactions greater that 100K to be non-standard, so the vulnerability is further reduced.<br /> <br /> == Suggested Solution for 0.6/0.7 versions ==<br /> <br /> <br /> The client application could verify that prevouts are not spent each time they are fetched, and abort if a spent prevout is found.<br /> <br /> bool CTransaction::FetchInputs(CTxDB&amp; txdb, const map&lt;uint256, CTxIndex&gt;&amp; mapTestPool,<br /> bool fBlock, bool fMiner, MapPrevTx&amp; inputsRet, bool&amp; fInvalid)<br /> {<br /> ..<br /> for (unsigned int i = 0; i &lt; vin.size(); i++)<br /> {<br /> // Read txPrev<br /> CTransaction&amp; txPrev = inputsRet[prevout.hash].second;<br /> ....<br /> // NEW CODE BEGINS<br /> if (prevout.n &gt;= txPrev.vout.size() || prevout.n &gt;= txindex.vSpent.size())<br /> {<br /> fInvalid = true;<br /> return DoS(100, error(&quot; .....<br /> }<br /> if (!txindex.vSpent[prevout.n].IsNull())<br /> return false;<br /> // NEW CODE ENDS<br /> }<br /> }<br /> <br /> <br /> == Disclosure Timeline ==<br /> <br /> 2013-01-09 - Vulnerability reported to Gavin Andressen and other core devs.&lt;br /&gt;<br /> 2013-01-09 - Gavin Andressen acknowledges report and confirms version 0.8 will not be vulnerable, permits disclosure after 0.8.0 release candidate 1 is available.&lt;br /&gt;<br /> 2013-02-09 - Bitcoin version 0.8.0 release candidate 1 is available, fixing the vulnerability&lt;br /&gt;<br /> 2013-02-14 - Vulnerability disclosure&lt;br /&gt;<br /> <br /> == Credit ==<br /> <br /> This vulnerability was discovered by Sergio Demian Lerner, from Certimix.com.<br /> This report was written by SDL.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=CVE-2012-4684&diff=35886 2013-03-05T19:29:06Z

<p>Sergio Demian Lerner: Created page with &quot;== Network-wide DoS using malleable signatures in alerts == Private Release Date: 24-AGO-2012&lt;br /&gt; Public Release Date: 01-MAR-2013&lt;br /&gt; == Systems Affected == * Satoshi ...&quot;</p> <hr /> <div>== Network-wide DoS using malleable signatures in alerts ==<br /> <br /> Private Release Date: 24-AGO-2012&lt;br /&gt;<br /> Public Release Date: 01-MAR-2013&lt;br /&gt;<br /> <br /> == Systems Affected ==<br /> <br /> * Satoshi Bitcoin Client (Bitcoin-Qt, bitcoind)<br /> * All Bitcoin clients that mimic the behavior related to the alert system of Satoshi client versions prior 0.6.3<br /> <br /> == Affected Versions ==<br /> <br /> * Bitcoin version 0.6.3 released 2012-06-25<br /> * Bitcoin version 0.6.2 released 2012-05-08<br /> * Bitcoin version 0.6.1 released 2012-05-04<br /> * Bitcoin version 0.6.0 released 2012-03-30<br /> * Bitcoin version 0.5.3.1 released 2012-03-16<br /> * Bitcoin version 0.5.3 released 2012-03-14<br /> * Bitcoin version 0.5.2 released 2012-01-09<br /> * Bitcoin version 0.5.1 released 2011-12-15<br /> * Bitcoin version 0.5.0 released 2011-11-21<br /> * Bitcoin version 0.4.0 released 2011-09-23<br /> * Bitcoin version 0.3.24 released 2011-07-08<br /> * Bitcoin version 0.3.23 released 2011-06-14<br /> * Bitcoin version 0.3.22 released 2011-06-05<br /> * Bitcoin version 0.3.21 released 2011-04-27<br /> <br /> == Fixed in version ==<br /> <br /> * Bitcoin version 0.7.0 released 2012-09-17<br /> <br /> == Overview ==<br /> <br /> Bitcoin protocol has an alert system to spread important news regarding the digital currency. Alerts are signed with a private ECDA key, so only the development team can issue new alerts. Nevertheless, prior version 0.7.0, alerts were identified by the hash of the message, which includes the signature. Bitcoin accepts BED-encoded signatures, which are malleable.<br /> An attacker build new signatures at a high rate by changing the signature of an alert still in circulation and therefore increasing dramatically the number of valid alerts spreading across the network. This leads to halting all Bitcoin nodes in the network by RAM exhaustion in approximately 4 hours. The attack is persistent, since if a nodes restarted get flooded again by online peers.<br /> <br /> == Details ==<br /> <br /> There different ways an attacker can abuse the malleability of alert signatures:<br /> <br /> - 1. An attacker may try to fill the RAM of all the nodes by sending 2000 modified alerts, each of 1 Mbyte size, using padding zeros. Such 1 Mbyte alerts would slowly spread through the network, and finally reach every node.<br /> <br /> - 2. An attacker may use the fact that an ECDSA signature consist of two numbers (r,s), and each one can be padded by zeros. By interleaving and extending the zero padding of s and r, the attacker can build a stream of correct signatures whose sizes grows with the square root of the number of signatures generated.<br /> (for example, for X bytes of zero-padding you can generate X different modified signature alerts whose sizes are size(r)=72+i, size(s)=72+X-i for 0 &lt;= i &lt;= X)<br /> <br /> This attack can try to exhaust GUI resources. For example, running the attack for 1 hour over a 64 Kbytes/sec link, the attacker is able to produce 321446 alerts. We have not evaluated how Qt responds in each platform to 321446 calls to QMessageBox::critical() without user interaction, but it's plausible that the application halts.<br /> <br /> - 3. An attacker can try to exhaust the victim's computer CPU by:<br /> <br /> - 3.1. Forcing excessive signature verification time (this only happens with the very first small alerts sent, and for old CPUs )<br /> <br /> - 3.2. Forcing excessive iterations of the loop : for (map&lt;uint256, CAlert&gt;::iterator mi = mapAlerts.begin(); mi != mapAlerts.end()Wink<br /> <br /> As an example, in the first hour an attacker is able to send 321446 small alerts. The following hour the attacker is able to send 207757 alerts, starting at size 1218. With a 64 Kbytes/sec link, the attacker can send this last alerts at 52 alerts/second. The code block inside the for loop will be executed 321446*52 = 16,890,430 times, and that takes more than a second to process on an average computer, so CPU is exhausted in the loop.<br /> <br /> To maximize the damage of an attack, an attacker requires an existing alert that is relevant for all versions of the protocol, and one that will not have expired and is still in the relay interval. With such alert, the attacker can reach the maximum number of nodes. Because of this, the vulnerability should not be notified to users by using the alert system. By doing so the attacker may receive the tool required to mount the best possible attack.<br /> <br /> == Attack Scenario ==<br /> <br /> The best attack is to harm the entire network and possibly generate a rush to the coin. To simplify the analysis, we assume that an average connection bandwidth is 64 Kbytes/sec and that each node has 2 GB of RAM, plus 2 GB of swap space. We assume the attacker executes the attack 1 described in the previous section, which tries to exhaust RAM, but leaves the CPU resources intact to keep spreading the fake alerts. If the such an attack is executed, every node in the network will start trashing after 1.5 hours approximately, as Bitcoin application will be using more than 1.5 GB of RAM. After 2 hours, every node running in Windows 32-bits will halt, since the address space of 2 Gb will be filled. After 8.7 hours, every 64-bit node still alive will fill both the 2 Gb of RAM and the 4 gigabytes of hard disk swap space assumed, and the Bitcoin application will halt.<br /> <br /> It is supposed that, in Bitcoin-Qt application, QMessageBox::critical() with modal=false will be called for each alert, so the application may crash much sooner due to lack of Windows or whatever GUI resources Qt uses. This is only relevant to Bitcoin-qt and not Bitcoind releases.<br /> <br /> == Suggested Solutions for the 0.7.0 release ==<br /> <br /> # Change the way the hash of alerts is computed: exclude the signature from the hash.<br /> # Reject alert signatures that are not DER-encoded.<br /> # Check setKnown before checking signatures.<br /> # Support a special fixed alert message that cancels all previous alerts. This would be a damage control measure if all other protections are violated.<br /> <br /> Solutions 1,3 and 4 were implemented in Bitcoin version 0.7.0.<br /> <br /> == Disclosure Time-line ==<br /> <br /> 2012-08-24 - Vulnerability reported to Gavin Andressen and other core devs.&lt;br /&gt;<br /> 2012-08-24 - Gavin Andressen acknowledges report&lt;br /&gt;<br /> 2012-08-26 – Private discussions of Gavin Andressen, Gregory Maxwell and Sergio Lerner on how to address the vulnerability.&lt;br /&gt;<br /> 2012-08-26 – Fix finally scheduled for the 0.7.0 release&lt;br /&gt;<br /> 2012-09-17 - Bitcoin version 0.7.0 released&lt;br /&gt;<br /> 2013-03-01 - Patched Bitcoin versions reach 80% of the network nodes upgraded.&lt;br /&gt;<br /> 2013-03-01 - Vulnerability disclosure&lt;br /&gt;<br /> <br /> == Credit ==<br /> <br /> This vulnerability was discovered by Sergio Demian Lerner, from [http://Certimix.com Certimix.com].&lt;br /&gt;<br /> Bitcointalk user Enochian was the first to publish BER/DER encoding problems of Bitcoin signatures in this thread: https://bitcointalk.org/index.php?topic=8392.0. &lt;br /&gt;<br /> This report was written by SDL.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=CVE-2012-4683&diff=35885 2013-03-05T19:24:13Z

<p>Sergio Demian Lerner: Created page with &quot;== Targeted DoS by CPU exhaustion using alerts == Private Release Date: 23-AGO-2012&lt;br /&gt; Public Release Date: 01-MAR-2013&lt;br /&gt; == Systems Affected == * Satoshi Bitcoin Cl...&quot;</p> <hr /> <div>== Targeted DoS by CPU exhaustion using alerts ==<br /> <br /> Private Release Date: 23-AGO-2012&lt;br /&gt;<br /> Public Release Date: 01-MAR-2013&lt;br /&gt;<br /> <br /> == Systems Affected ==<br /> <br /> * Satoshi Bitcoin Client (Bitcoin-Qt, bitcoind)<br /> * All Bitcoin clients that mimic the behavior related to the alert system of Satoshi client versions prior 0.6.3<br /> <br /> == Affected Versions ==<br /> <br /> * Bitcoin version 0.6.3 released 2012-06-25<br /> * Bitcoin version 0.6.2 released 2012-05-08<br /> * Bitcoin version 0.6.1 released 2012-05-04<br /> * Bitcoin version 0.6.0 released 2012-03-30<br /> * Bitcoin version 0.5.3.1 released 2012-03-16<br /> * Bitcoin version 0.5.3 released 2012-03-14<br /> * Bitcoin version 0.5.2 released 2012-01-09<br /> * Bitcoin version 0.5.1 released 2011-12-15<br /> * Bitcoin version 0.5.0 released 2011-11-21<br /> * Bitcoin version 0.4.0 released 2011-09-23<br /> * Bitcoin version 0.3.24 released 2011-07-08<br /> * Bitcoin version 0.3.23 released 2011-06-14<br /> * Bitcoin version 0.3.22 released 2011-06-05<br /> * Bitcoin version 0.3.21 released 2011-04-27<br /> <br /> == Fixed in version ==<br /> <br /> * Bitcoin version 0.7.0 released 2012-09-17<br /> <br /> == Overview ==<br /> <br /> Bitcoin protocol has an alert system to spread important news regarding the digital currency. Alerts are signed with a private ECDA key, so only the development team can issue new alerts. Alerts signatures are checked for every alert that is received. Each check takes some time, usually between 1 and 4 msecs. The verification time does not depend on the correctness of the signature. Therefore an attacker may flood a node with invalid alerts generated on-the-fly at no cost, and exhaust the victim's node CPU.<br /> <br /> == Details ==<br /> <br /> The Satoshi client prior version 0.7.0 does not define an alert signature verification failure as a DoS attack (using return DoS(...); ).<br /> <br /> A malicious client app can start sending invalid alerts at a rate of almost 3000 alerts/second for a 64 Kbytes/sec link. The victim's computer will reach 100% CPU utilization for the core associated with the ThreadMessageHandler2() thread. Although that thread has priority THREAD_PRIORITY_BELOW_NORMAL, the computer will suffer a noticeable slowdown. The attack works even with a 3 Kbytes/sec bandwidth usage, so even a slow network link can be used for the attack.<br /> <br /> Alerts can be as short as 10 bytes. Here is a complete alert (without network message headers) that has an incorrect signature:<br /> <br /> [0, 8, 48, 6, 2, 1, 10, 2, 1, 10]<br /> <br /> It has zero length payload and (r,s) = (10,10)<br /> <br /> The problem is still present even if you send the attacker sends correct alerts, previously received, since CheckSignature() is called before the signature is checked against mapAlerts. It was verified that, in an average computer, sending a 188-bytes correct alert continuously on a 64 Kbytes/sec link still rises the victim's CPU usage to 100%.<br /> <br /> == Possible Attack Scenarios ==<br /> <br /> * An attacker has a direct connection to the victim's node.<br /> * An attacker has a direct connections to a set of nodes that, if put off-line, could cut the network in two unconnected components. The attacker may try then to double-spend in each of the components. Since the attack requires very few resources for the attacker, he may try to attack all those nodes at once from a single computer.<br /> <br /> == Suggested Solutions for the 0.7.0 version ==<br /> <br /> # Disconnect from any node that sends a bad alert (return DoS(...))<br /> # Check that an alert is not verified more than once by checking the existence of the alert in mapAlerts before doing a CheckSignature()<br /> <br /> Both solutions were adopted in version 0.7.0, although a lower penalty is given to nodes for sending single incorrect alerts.<br /> <br /> == Disclosure Timeline ==<br /> <br /> 2012-08-23 - Vulnerability reported to Gavin Andressen and other core devs.&lt;br /&gt;<br /> 2012-08-23 - Gavin Andressen acknowledges report and asserts that version 0.7 will be patched against these problems.&lt;br /&gt;<br /> 2012-09-17 - Bitcoin version 0.7.0 released&lt;br /&gt;<br /> 2013-03-01 - Patched Bitcoin version reach 80% of the network nodes upgraded.&lt;br /&gt;<br /> 2013-03-01 - Vulnerability disclosure&lt;br /&gt;<br /> <br /> == Credit ==<br /> <br /> This vulnerability was discovered by Sergio Demian Lerner, from [http://Certimix.com Certimix.com].<br /> This report was written by SDL.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=35884 2013-03-05T19:16:58Z

<p>Sergio Demian Lerner: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:16ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 99%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 95%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 100%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 95%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 95%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | (Lack of) orphan txn resource limits<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 90%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 80%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | 2012-08-23<br /> | bitcoind and Bitcoin-Qt<br /> | bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | bgcolor=pink| Easy<br /> | Targeted DoS by CPU exhaustion using alerts<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 80%]<br /> |-<br /> | [[#CVE-2012-4684|CVE-2012-4684]]<br /> | 2012-08-24<br /> | bitcoind and Bitcoin-Qt<br /> | bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | bgcolor=pink| Easy<br /> | Network-wide DoS using malleable signatures in alerts<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124683 80%]<br /> |-<br /> | [[#CVE-2013-2272|CVE-2013-2272]]<br /> | 2013-01-11<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Remote discovery of node's wallet addresses<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132272 22%]<br /> |-<br /> | [[#CVE-2013-2273|CVE-2013-2273]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=lime| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=yellow| Easy<br /> | Predictable change output<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132273 22%]<br /> |-<br /> | [[#CVE-2013-2292|CVE-2013-2292]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=lime| Hard<br /> | A transaction that takes at least 3 minutes to verify<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132292 -]<br /> |-<br /> | [[#CVE-2013-2293|CVE-2013-2293]]<br /> | 2013-02-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Continuous hard disk seek<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293 22%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 80%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [https://bitcointalk.org/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; (Lack of) orphan txn resource limits<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 90%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == CVE-2012-4682 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; <br /> &lt;b&gt;Summary:&lt;/b&gt; <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4682]]<br /> <br /> == CVE-2012-4683 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-08-23<br /> &lt;b&gt;Summary:&lt;/b&gt; Targeted DoS by CPU exhaustion using alerts<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.7.0 <br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4683]]<br /> * [https://bitcointalk.org/index.php?topic=148038.0 Announcement]<br /> <br /> == CVE-2012-4684 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-08-24<br /> &lt;b&gt;Summary:&lt;/b&gt; Network-wide DoS using malleable signatures in alerts<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 - 0.6.3rc1 || 0.7.0 <br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4684]]<br /> * [https://bitcointalk.org/index.php?topic=148109.0 Announcement]<br /> <br /> == CVE-2013-2272 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Remote discovery of node's wallet addresses<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> === References ===<br /> <br /> * [https://bitcointalk.org/?topic=135856 Announcement]<br /> <br /> == CVE-2013-2273 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; Predictable change output <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> == CVE-2013-2292 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; A transaction that takes at least 3 minutes to verify<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; -<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || All versions || No fix yet<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2013-2292]]<br /> * [https://bitcointalk.org/?topic=140078 Announcement]<br /> <br /> == CVE-2013-2293 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-02-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Continuous hard disk seek<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.7.3rc1 || No fix yet (0.8.0 unaffected)<br /> |}<br /> <br /> === References ===<br /> <br /> * [[CVE-2013-2293]]<br /> * [https://bitcointalk.org/?topic=144122 Announcement]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=35883 2013-03-05T19:13:59Z

<p>Sergio Demian Lerner: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:16ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 99%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 95%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 100%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 95%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 95%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | (Lack of) orphan txn resource limits<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 90%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 80%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 80%]<br /> |-<br /> | [[#CVE-2012-4684|CVE-2012-4684]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124683 80%]<br /> |-<br /> | [[#CVE-2013-2272|CVE-2013-2272]]<br /> | 2013-01-11<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Remote discovery of node's wallet addresses<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132272 22%]<br /> |-<br /> | [[#CVE-2013-2273|CVE-2013-2273]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=lime| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=yellow| Easy<br /> | Predictable change output<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132273 22%]<br /> |-<br /> | [[#CVE-2013-2292|CVE-2013-2292]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=lime| Hard<br /> | A transaction that takes at least 3 minutes to verify<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132292 -]<br /> |-<br /> | [[#CVE-2013-2293|CVE-2013-2293]]<br /> | 2013-02-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Continuous hard disk seek<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293 22%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 80%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [https://bitcointalk.org/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; (Lack of) orphan txn resource limits<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 90%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == CVE-2012-4682 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; <br /> &lt;b&gt;Summary:&lt;/b&gt; <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4682]]<br /> <br /> == CVE-2012-4683 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-08-23<br /> &lt;b&gt;Summary:&lt;/b&gt; Targeted DoS by CPU exhaustion using alerts<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.7.0 <br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4683]]<br /> * [https://bitcointalk.org/index.php?topic=148038.0 Announcement]<br /> <br /> == CVE-2012-4684 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-08-24<br /> &lt;b&gt;Summary:&lt;/b&gt; Network-wide DoS using malleable signatures in alerts<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 - 0.6.3rc1 || 0.7.0 <br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-4684]]<br /> * [https://bitcointalk.org/index.php?topic=148109.0 Announcement]<br /> <br /> == CVE-2013-2272 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Remote discovery of node's wallet addresses<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> === References ===<br /> <br /> * [https://bitcointalk.org/?topic=135856 Announcement]<br /> <br /> == CVE-2013-2273 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; Predictable change output <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> == CVE-2013-2292 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; A transaction that takes at least 3 minutes to verify<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; -<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || All versions || No fix yet<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2013-2292]]<br /> * [https://bitcointalk.org/?topic=140078 Announcement]<br /> <br /> == CVE-2013-2293 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-02-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Continuous hard disk seek<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.7.3rc1 || No fix yet (0.8.0 unaffected)<br /> |}<br /> <br /> === References ===<br /> <br /> * [[CVE-2013-2293]]<br /> * [https://bitcointalk.org/?topic=144122 Announcement]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=35882 2013-03-05T18:59:51Z

<p>Sergio Demian Lerner: /* References */</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:16ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 99%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 95%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 100%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 95%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 95%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | (Lack of) orphan txn resource limits<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 90%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 80%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 80%]<br /> |-<br /> | [[#CVE-2012-4684|CVE-2012-4684]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124683 80%]<br /> |-<br /> | [[#CVE-2013-2272|CVE-2013-2272]]<br /> | 2013-01-11<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Remote discovery of node's wallet addresses<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132272 22%]<br /> |-<br /> | [[#CVE-2013-2273|CVE-2013-2273]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=lime| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=yellow| Easy<br /> | Predictable change output<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132273 22%]<br /> |-<br /> | [[#CVE-2013-2292|CVE-2013-2292]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=lime| Hard<br /> | A transaction that takes at least 3 minutes to verify<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132292 -]<br /> |-<br /> | [[#CVE-2013-2293|CVE-2013-2293]]<br /> | 2013-02-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Continuous hard disk seek<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293 22%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 80%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [https://bitcointalk.org/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; (Lack of) orphan txn resource limits<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 90%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == CVE-2013-2272 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Remote discovery of node's wallet addresses<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> === References ===<br /> <br /> * [https://bitcointalk.org/?topic=135856 Announcement]<br /> <br /> == CVE-2013-2273 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; Predictable change output <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> == CVE-2013-2292 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; A transaction that takes at least 3 minutes to verify<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; -<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || All versions || No fix yet<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2013-2292]]<br /> * [https://bitcointalk.org/?topic=140078 Announcement]<br /> <br /> == CVE-2013-2293 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-02-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Continuous hard disk seek<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.7.3rc1 || No fix yet (0.8.0 unaffected)<br /> |}<br /> <br /> === References ===<br /> <br /> * [[CVE-2013-2293]]<br /> * [https://bitcointalk.org/?topic=144122 Announcement]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=CVE-2013-2293&diff=35881 2013-03-05T18:58:44Z

<p>Sergio Demian Lerner: Created page with &quot;&#039;&#039;&#039;New DoS vulnerability by Forcing Continuous Hard Disk Seek/Read Activity&#039;&#039;&#039; Private Release Date: 08-JAN-2013&lt;br /&gt; Public Release Date: 14-FEB-2013&lt;br /&gt; &#039;&#039;&#039;Systems Aff...&quot;</p> <hr /> <div>'''New DoS vulnerability by Forcing Continuous Hard Disk Seek/Read Activity'''<br /> <br /> Private Release Date: 08-JAN-2013&lt;br /&gt;<br /> Public Release Date: 14-FEB-2013&lt;br /&gt;<br /> <br /> <br /> '''Systems Affected'''<br /> <br /> * Satoshi Bitcoin Client (Bitcoin-Qt, bitcoind)<br /> * All Bitcoin clients that mimic the behavior related to transaction validation of Satoshi client versions prior 0.8.0<br /> <br /> '''Affected Versions'''<br /> <br /> * Bitcoin version 0.7.2 released 2012-12-14<br /> * Bitcoin version 0.7.1 released 2012-10-19<br /> * Bitcoin version 0.7.0 released 2012-09-17<br /> * Bitcoin version 0.6.3 released 2012-06-25<br /> * Bitcoin version 0.6.2 released 2012-05-08<br /> * Bitcoin version 0.6.1 released 2012-05-04<br /> * Bitcoin version 0.6.0 released 2012-03-30<br /> * Bitcoin version 0.5.3.1 released 2012-03-16<br /> * Bitcoin version 0.5.3 released 2012-03-14<br /> * Bitcoin version 0.5.2 released 2012-01-09<br /> * Bitcoin version 0.5.1 released 2011-12-15<br /> * Bitcoin version 0.5.0 released 2011-11-21<br /> * Bitcoin version 0.4.0 released 2011-09-23<br /> * Bitcoin version 0.3.24 released 2011-07-08<br /> * Bitcoin version 0.3.23 released 2011-06-14<br /> * Bitcoin version 0.3.22 released 2011-06-05<br /> * Bitcoin version 0.3.21 released 2011-04-27<br /> <br /> <br /> '''Overview'''<br /> <br /> Transaction processing has two stages in Satoshi Bitcoin client. In the first stage, transaction inputs are fetched.<br /> This is done by bringing to RAM the transactions that contains the outputs referred by the inputs.<br /> In the second stage, previous outputs are verified to be unspent and the related scripts are evaluated.<br /> Since double spends are not considered to be a DoS attempt by the protocol rules, a transaction that refers to previous spent outputs will pass the first processing stage without being discarded. An attacker can therefore construct transactions that, before being discarded in the second stage of processing, require the victim application to seek and read too many parts of the block chain that could be scattered thought the storage files, delaying any other processing.<br /> <br /> '''Details'''<br /> <br /> We assume that the whole block chain does not fit in RAM, so each transaction fetch requires a HD seek and read. An average 7200 rpm hard drive<br /> can random seek/read a 1Kb block in a non-cached 2 Gb file in 12 msec. Each prevout of a transaction consumes 44 bytes, with empty sigscripts.<br /> The attacker creates transaction with many inputs an one output. In this way, the other sections of the transaction (output scripts, headers) are amortized and become irrelevant to this analysis.<br /> For an Internet connection of 50 Kbytes/sec bandwidth, sending 45 bytes requires less than 1 msec.<br /> By continuously sending this specially crafted transactions an attacker can block any Bitcoin peer from performing other tasks.<br /> Also the attacker may be able to block 10 peers at the same time, since the relation of 1:10 in required resources.<br /> Note that the attacker does not need to sign the inputs nor to have the full block-chain to perform the attack. He only requires the hashes of all previous transactions, which currently requires only 10876856*32=332 Mbytes of storage.<br /> <br /> Version 0.8.0 of the Satoshi client stores only unspent prevouts in memory and can abort processing right after a spent prevout is referred by a transaction.<br /> <br /> '''Possible Attack Scenarios'''<br /> <br /> 1. Because of the small resources required to mount the attack, it could be performed by botnets to massively attack the Bitcoin network.<br /> <br /> 2. The attack can be used against miners to prevent them from sending blocks. Nevertheless, currently big miners are only connected to there own front-line of Bitcoin nodes to preven such attacks.<br /> <br /> 3. By using many nodes at once, an attacker may try to create a barrier that splits the network in unconnected components, in order to carry another kind of attack.<br /> <br /> '''Not-a-problem variations'''<br /> <br /> 1. A valid 1M transaction could be constructed to reference more than 22K unique input transactions. In theory that transaction would take more than 5 minutes to be verified. Nevertheless the attack is unpractical for two reasons:&lt;br /&gt;<br /> a. The attacker should have to own those 22K transactions.&lt;br /&gt;<br /> b. Those 22K transactions should have to be scattered thought the blockchain to force HD seeking activity. If they were created in a limited period of time, they would end up confined in a limited portion of the block chain file. The result would be that the hard disk cache will help to reduce the read latency and so attack effectiveness will be reduced. Nevertheless version 0.8.0 of the Satoshi client considers transactions greater that 100K to be non-standard, so the vulnerability is further reduced.<br /> <br /> '''Suggested Solution for 0.6/0.7 versions'''<br /> <br /> <br /> The client application could verify that prevouts are not spent each time they are fetched, and abort if a spent prevout is found.<br /> <br /> bool CTransaction::FetchInputs(CTxDB&amp; txdb, const map&lt;uint256, CTxIndex&gt;&amp; mapTestPool,<br /> bool fBlock, bool fMiner, MapPrevTx&amp; inputsRet, bool&amp; fInvalid)<br /> {<br /> ..<br /> for (unsigned int i = 0; i &lt; vin.size(); i++)<br /> {<br /> // Read txPrev<br /> CTransaction&amp; txPrev = inputsRet[prevout.hash].second;<br /> ....<br /> // NEW CODE BEGINS<br /> if (prevout.n &gt;= txPrev.vout.size() || prevout.n &gt;= txindex.vSpent.size())<br /> {<br /> fInvalid = true;<br /> return DoS(100, error(&quot; .....<br /> }<br /> if (!txindex.vSpent[prevout.n].IsNull())<br /> return false;<br /> // NEW CODE ENDS<br /> }<br /> }<br /> <br /> <br /> '''Disclosure Timeline'''<br /> <br /> 2013-01-09 - Vulnerability reported to Gavin Andressen and other core devs.&lt;br /&gt;<br /> 2013-01-09 - Gavin Andressen acknowledges report and confirms version 0.8 will not be vulnerable, permits disclosure after 0.8.0 release candidate 1 is available.&lt;br /&gt;<br /> 2013-02-09 - Bitcoin version 0.8.0 release candidate 1 is available, fixing the vulnerability&lt;br /&gt;<br /> 2013-02-14 - Vulnerability disclosure&lt;br /&gt;<br /> <br /> '''Credit'''<br /> <br /> This vulnerability was discovered by Sergio Demian Lerner, from Certimix.com.<br /> This report was written by SDL.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=35880 2013-03-05T18:51:14Z

<p>Sergio Demian Lerner: /* CVE-2013-2293 */</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:16ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 99%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 95%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 100%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 95%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 95%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | (Lack of) orphan txn resource limits<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 90%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 80%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 80%]<br /> |-<br /> | [[#CVE-2012-4684|CVE-2012-4684]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |<br /> | <br /> | <br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20124683 80%]<br /> |-<br /> | [[#CVE-2013-2272|CVE-2013-2272]]<br /> | 2013-01-11<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Remote discovery of node's wallet addresses<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132272 22%]<br /> |-<br /> | [[#CVE-2013-2273|CVE-2013-2273]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=lime| Exposure&lt;ref name=&quot;Exposure&quot;/&gt;<br /> |bgcolor=yellow| Easy<br /> | Predictable change output<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132273 22%]<br /> |-<br /> | [[#CVE-2013-2292|CVE-2013-2292]]<br /> | 2013-01-30<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=lime| Hard<br /> | A transaction that takes at least 3 minutes to verify<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132292 -]<br /> |-<br /> | [[#CVE-2013-2293|CVE-2013-2293]]<br /> | 2013-02-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Continuous hard disk seek<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/security.html?20132293 22%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 80%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [https://bitcointalk.org/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 95%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; (Lack of) orphan txn resource limits<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 90%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == CVE-2013-2272 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Remote discovery of node's wallet addresses<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> === References ===<br /> <br /> * [https://bitcointalk.org/?topic=135856 Announcement]<br /> <br /> == CVE-2013-2273 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; Predictable change output <br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.8rc4&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.10rc4&lt;br&gt;0.6.1rc1 - 0.6.4rc4&lt;br&gt;0.7.0rc1 - 0.7.2 || 0.4.9rc1&lt;br&gt;0.5.8rc1&lt;br&gt;0.6.0.11rc1&lt;br&gt;0.6.5rc1&lt;br&gt;0.7.3rc1<br /> |}<br /> <br /> == CVE-2013-2292 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-01-30<br /> &lt;b&gt;Summary:&lt;/b&gt; A transaction that takes at least 3 minutes to verify<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; -<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || All versions || No fix yet<br /> |}<br /> <br /> === References ===<br /> <br /> * [https://bitcointalk.org/?topic=140078 Announcement]<br /> <br /> == CVE-2013-2293 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2013-02-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Continuous hard disk seek<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 22%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.7.3rc1 || No fix yet (0.8.0 unaffected)<br /> |}<br /> <br /> === References ===<br /> <br /> * [[CVE-2013-2293]]<br /> * [https://bitcointalk.org/?topic=144122 Announcement]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 80%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=User:Sergio_Demian_Lerner&diff=35879 2013-03-05T14:07:55Z

<p>Sergio Demian Lerner: Created page with &quot;==Who am I?== Sergio Demian Lerner * Bitcoin security researcher * Master in Computer Science * Reporter of Bitcoin vulnerabilities [[Common_Vulnerabilities_and_Exposures|CV...&quot;</p> <hr /> <div>==Who am I?==<br /> Sergio Demian Lerner<br /> <br /> * Bitcoin security researcher <br /> * Master in Computer Science<br /> * Reporter of Bitcoin vulnerabilities [[Common_Vulnerabilities_and_Exposures|CVE-2012-3789, CVE-2012-4682, CVE-2012-4683, CVE-2012-4684, CVE-2013-2272, CVE-2013-2292 and CVE-2013-2293]]<br /> * Designer of Mental Poker protocol MPF.<br /> * My Blog: bitslog.wordpress.com<br /> * My Tweets: @SDLerner<br /> * My company: http://www.certimix.com/<br /> <br /> ==Bitcoin related publications==<br /> <br /> * [http://www.dc.uba.ar/inv/tesis/licenciatura/2010/lerner MPF: A new family of practical and secure Mental Poker protocols]<br /> Tesis de Licenciatura en Ciencias de la Computación, Facultad de Ciencias Exactas y Naturales, Universidad de Buenos Aires<br /> November 15, 2010<br /> <br /> In this thesis we propose a new family of practical and secure mental poker protocols, which are efficient enough to achieve real-time performance to security play Texas Hold-em over the Internet, for up to ten players, using personal computers.<br /> <br /> * [http://bitslog.wordpress.com/2012/04/09/mave-digital-signature-protocol-for-massive-bulk-verifications/ MAVE: Digital Signature Protocol for Massive bulk verifications]<br /> April 9, 2012<br /> <br /> In this paper we propose new decentralized digital signature protocols<br /> to allow massive bulk verifications (MAVE). The protocols satisfies very<br /> tight requirements of performance and storage. MAVE requires a third party<br /> with no special trust and a broadcast medium. MAVE can be used for groups<br /> of millions of users or autonomous agents that generate thousands of signatures<br /> per second that must...more<br /> <br /> * [http://bitslog.wordpress.com/2012/04/16/mavepay-a-new-lightweight-payment-scheme-for-peer-to-peer-currency-networks/ MAVEPAY: a new lightweight payment scheme for peer to peer currency networks]<br /> April 16, 2012<br /> <br /> In this paper we propose a new payment scheme based on the<br /> MAVE digital signature protocol, for use in peer to peer currency networks<br /> based on a block chain. The proposed payment scheme requires less resources<br /> for the users than Bitcoin and can be used to create a truly lightweight peer<br /> to peer currency network that stands 700 payments/second, and 5 million new<br /> user accounts/year, on an...more<br /> <br /> * [http://bitslog.wordpress.com/2012/08/06/destination-address-anonymization-in-bitcoin/ Destination Address Anonymization in Bitcoin]<br /> August 6, 2012<br /> <br /> Protocol proposal for anonymous customer-merchant relations in Bitcoin.<br /> <br /> * [http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/ Bitmessage v1.0: completely broken crypto]<br /> November 30, 2012<br /> <br /> Description of security vulnerabilities of the Bitmessage protocol 1.0<br /> <br /> * [http://bitslog.wordpress.com/2013/01/23/the-bitcoin-trasaction-fetch-memory-exhaustion-attack-tfmea/ The Bitcoin transaction fetch memory exhaustion attack (TFMEA)]<br /> January 23, 2013<br /> <br /> Disclosure of a DoS vulnerability in Bitcoin clients.<br /> <br /> * [http://bitslog.wordpress.com/2013/01/23/new-bitcoin-vulnerability-get-your-peer-public-addresses/ Get your peer public addresses]<br /> January 23, 2013<br /> <br /> Disclosure of a vulnerability in Bitcoin that breaks its pseudo - anonymization.<br /> <br /> * [http://bitslog.wordpress.com/2013/01/08/cve-2012-3789-disclosure/ CVE-2012-3789 disclosure]<br /> January 8, 2013<br /> <br /> Disclosure of 3 DoS vulnerabilities I found in Bitcoin.<br /> <br /> * [http://www.bouncycastle.org/jira/browse/BJB-22 Vulnerability in BouncyCastle ECDSA signature verification]<br /> February 19, 2013<br /> <br /> Disclosure of a security vulnerability found in BouncyCastle ECDSA signature verification code that, in applications that must verify other people's signatures, can result in remote application terminations and DoS attack. If affects Bitcoin nodes coded in Java/C# that uses the Bouncycastle cryptographic library.<br /> <br /> ==My Patents==<br /> <br /> * METHOD AND APPARATUS FOR EFFICIENT AND SECURE CREATING, TRANSFERRING, AND REVEALING OF MESSAGES OVER A NETWORK<br /> United States 12/904,033<br /> Filed October 13, 2009<br /> <br /> The patent describes a new realtime peer to peer method for playing with cards over a network with cryptographic security (a '''Mental Poker protocol''')<br /> <br /> * METHOD AND APPARATUS FOR EFFICIENT AND SECURE CREATING, TRANSFERRING, AND REVEALING OF MESSAGES OVER A NETWORK<br /> Europe PCT/US10/52550<br /> Filed October 13, 2009<br /> <br /> == See also ==<br /> *[[Research]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=35691 2013-02-22T19:16:33Z

<p>Sergio Demian Lerner: /* Denial of Service (DoS) attacks */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions (protects from https://bitcointalk.org/index.php?topic=136422.0 attack)<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> <br /> These are the Satoshi client protections added in version 0.8.0: <br /> <br /> # Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).<br /> # Only the UXTO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.<br /> # 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)<br /> <br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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.<br /> 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=34824 2013-01-08T17:56:13Z

<p>Sergio Demian Lerner: </p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:14ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 97%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 88%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 99%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 88%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 88%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | Easy<br /> | Multiple DoS Vulnerabilties in Satoshi Bitcoin client<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 &gt;74%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 47%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 47%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 47%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [http://www.bitcoin.org/smf/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [http://www.bitcoin.org/smf/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 97%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; Multiple DoS Vulnerabilties in Satoshi Bitcoin client<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; &gt;74%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 47%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1&lt;br&gt;0.7.0rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=CVE-2012-3789&diff=34823 2013-01-08T17:53:10Z

<p>Sergio Demian Lerner: Created page with &quot;== Multiple DoS Vulnerabilties in Satoshi Bitcoin client == Private Release Date: 12-MAY-2012&lt;br /&gt; Public Release Date: 08-JAN-2013&lt;br /&gt; === Systems Affected === ---------...&quot;</p> <hr /> <div>== Multiple DoS Vulnerabilties in Satoshi Bitcoin client ==<br /> <br /> Private Release Date: 12-MAY-2012&lt;br /&gt;<br /> Public Release Date: 08-JAN-2013&lt;br /&gt;<br /> <br /> === Systems Affected ===<br /> ----------------<br /> <br /> - Satoshi Bitcoin Client (Bitcoin-Qt, bitcoind)&lt;br /&gt;<br /> - All Bitcoin clients that mimic Satoshi client behaviour related to orphan transactions&lt;br /&gt;<br /> <br /> === Affected Versions ===<br /> -----------------<br /> <br /> - Bitcoin version 0.5.3, released 14 March 2012&lt;br /&gt;<br /> - Bitcoin version 0.5.3.1 released 16 March 2012&lt;br /&gt;<br /> - Bitcoin version 0.6.0 released 30 March 2012&lt;br /&gt;<br /> - Bitcoin version 0.6.1 released 4 May 2012&lt;br /&gt;<br /> - Bitcoin version 0.6.2 released 8 May 2012&lt;br /&gt;<br /> <br /> === Overview ===<br /> --------<br /> <br /> This report contains information regarding two new vulnerabilities discovered in May-2012. The more severe one allows a <br /> connected peer to hang the victim's client application in less than 20 minutes by sending a stream of specially <br /> crafted transactions, as a denial-of-service attack.<br /> <br /> === Background ===<br /> ----------<br /> <br /> Each peer defines a transaction as &quot;Orhpan&quot; if the transaction references a parent transaction (previous output) which is<br /> neither part of a block in the current best chain, nor it is in the in-memory transaction pool.<br /> Before version 0.5.3 of Satoshi Bitcoin client, orphan transactions were stored in a temporary table in memory until the parent transactions could be located in a block or the parent transaction was forwarded by a peer.<br /> The storage for ophan transaction was unlimited. This feature allowed an attacker to perform a DoS attack by sending transactions continuously until the victim's virtual memory was filled and the victim's operating system began trashing. This situation probably leads to the victim's computer or application to hang. <br /> The time needed for this DoS attack varies depending on the link bandwidth between the attacker and the victim, and the victim's RAM size. For an average computer and Internet connection it takes approximately 12 hours.<br /> <br /> The vulnerability was discovered by Sergio Demian Lerner and communicated to the Bitcoin.org development team, who developed and applied a patch (https://github.com/bitcoin/bitcoin/pull/911) that was incorporated in version 0.5.3. <br /> The patch limits the number of orphan transactions that are stored in memory and randomly erases a previous stored transaction on the arrival of a new one, if the memory table becomes full.<br /> <br /> Unfortunately the patch is ineffective and allows two new vectors of attack that are more severe than the original attack. The patched version still allows an attacker to fill the victim's memory with orphan transactions (see vulnerability 1) and it also allows an attacker to hang the victim's client application (see vulnerability 2) in less than 20 minutes. <br /> <br /> <br /> === Vulnerability 1 Details ===<br /> -----------------------<br /> <br /> Orphan transactions are stored in the table mapOrphanTransactions. The patch limits the number of entries to 10000 (constant MAX_ORPHAN_TRANSACTIONS). This number is arbitrary, and the criteria for the selection of the constant is unknown. Because transactions are not limited in size, is easy to create an orphan transaction whose size reaches <br /> 1 magabyte. If the transaction is built with thousands of random inputs (prevouts which are unknown to the victim app) then also the table mapOrphanTransactionsByPrev can fill the entire RAM. Prevouts whose hash is chosen at random would make trashing worse since virtual memory page faults will become inevitable. <br /> <br /> Suppose the attacker wants the victim to store 4 Gigabytes of data in virtual memory. Assume a 50 Kb/sec connection bandwidth.<br /> Then the attack takes approximately 11 hours.<br /> <br /> === Patching vulnerability 1 ===<br /> ------------------------<br /> <br /> The application must limit the amount of memory used by tables mapOrphanTransactions and mapOrphanTransactionsByPrev, either by counting the number of bytes used or by limiting the maximum size of each orphan transaction.<br /> <br /> Added note: Bitcoin version 0.6.3 and later only store orphan transactions whose size is less than 5000 byles. This limits the amount of memory that mapOrphanTransactions can consume, totalling no more than 50 Mbytes. Since the &quot;map&quot; data structure has a significant overhead when storing a single element, 5000 transactions that link to many random missing previns can force mapOrphanTransactionsByPrev to consume as high as 200 additional megabytes.<br /> <br /> Some extra security provisions may be implemented:<br /> <br /> * Prioritize orphan transactions that provide a proof of work per input (network protocol must be changed).<br /> * Limit the amount of transactions that each peer can send depending on the peer connection time (older peers get more bandwidth)<br /> <br /> === Vulnerability 2 Details ===<br /> -----------------------<br /> <br /> Each time a transaction must be erased from mapOrphanTransactions, all references to parent transactions must be erased from the table mapOrphanTransactionsByPrev too (see EraseOrphanTx()). The method wrongly assumes that the number of <br /> associations between a parent transaction and its potential childs is low, and so the code iterates through all pairs parent/child until the transaction to be erased is found. Code excerpt:<br /> <br /> BOOST_FOREACH(const CTxIn&amp; txin, tx.vin)<br /> {<br /> for (multimap&lt;uint256, CDataStream*&gt;::iterator mi = mapOrphanTransactionsByPrev.lower_bound(txin.prevout.hash);<br /> mi != mapOrphanTransactionsByPrev.upper_bound(txin.prevout.hash);)<br /> {<br /> if ((*mi).second == pvMsg)<br /> mapOrphanTransactionsByPrev.erase(mi++);<br /> else<br /> mi++;<br /> }<br /> }<br /> <br /> <br /> Each reference to a previous transaction is specified by a prevout, which is a hash of the transaction and an index of the outpoint referred. An attacker can send 10000 transactions that whose inputs refer to the same parent transaction (same hash), but specifying different indexes. Index numbers can be chosen incrementally (from 1 to 1M) since indexes cannot be verified to be out of range for a (still unknown) parent transaction.<br /> <br /> The attack is strengthened by the fact that client applications do not check for empty scripts in inputs, so each input size can be as low as 41 bytes. 11K transaction containing 100 fake inputs each is enough to hang a Satoshi client in an Intel Core 2 CPU 4300 running on a local testnet in less than a minute. If a connection of 50 Kb/sec is assumed, then the attack takes less than 20 minutes. Note that only one core of the CPU gets 100% of usage, because the client runs a single thread to process all messages from peers. Simulations were carried on on a local testnet, so the outcome of the attack on a real node (with plenty of peer connections) was not evaluated.<br /> <br /> === Patching vulnerability 2 ===<br /> ------------------------<br /> <br /> One possible change is to modify the mapOrphanTransactionsByPrev data structure from:<br /> <br /> multimap&lt;uint256, CDataStream*&gt; mapOrphanTransactionsByPrev;<br /> <br /> to:<br /> <br /> map&lt;uint256, map&lt;uint256,CDataStream*&gt; &gt; mapOrphanTransactionsByPrev;<br /> <br /> Example new EraseOrphanTx() method (not tested): <br /> <br /> void static EraseOrphanTx(uint256 hash)<br /> {<br /> if (!mapOrphanTransactions.count(hash))<br /> return;<br /> const CDataStream* pvMsg = mapOrphanTransactions[hash];<br /> CTransaction tx;<br /> BOOST_FOREACH(const CTxIn&amp; txin, tx.vin)<br /> {<br /> mapOrphanTransactionsByPrev[txin.prevout.hash].erase(hash);<br /> }<br /> mapOrphanTransactions.erase(hash);<br /> }<br /> <br /> <br /> Added note: Bitcoin version 0.6.3 and later includes this modification.<br /> <br /> === Disclosure Timeline ===<br /> -------------------<br /> <br /> * 2012-05-12 - Vulnerability reported to Gavin Andressen<br /> * 2012-05-17 - Gavin Andressen patches ready for review<br /> * 2012-06-20 - 0.6.3rc1 available for testing<br /> * 2012-06-25 - Bitcoin version 0.6.3 released, fixing the vulnerabilities.<br /> * 2013-01-08 - Vulnerability disclosure<br /> <br /> === Credit ===<br /> ------<br /> <br /> This vulnerability was discovered by Sergio Demian Lerner, from Certimix.com, who also did<br /> the vulnerability research and report editing for the public good.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&diff=34819 2013-01-08T17:41:01Z

<p>Sergio Demian Lerner: /* CVE-2012-3789 */</p> <hr /> <div>{| class=&quot;wikitable&quot;<br /> !style=&quot;width:14ex&quot;| CVE<br /> ! Announced !! Affects !! Severity !! Attack is... !! Flaw !! Net<br /> |-<br /> | [[#CVE-2010-5137|CVE-2010-5137]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;&gt;Attacker can disable some functionality, for example by crashing clients&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> | OP_LSHIFT crash<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5141|CVE-2010-5141]]<br /> | 2010-07-28<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;&gt;Attacker can take or create money outside known network rules&lt;/ref&gt;<br /> |bgcolor=pink| Easy<br /> |<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5138|CVE-2010-5138]]<br /> | 2010-07-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Unlimited SigOp DoS<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5139|CVE-2010-5139]]<br /> | 2010-08-15<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Theft&lt;ref name=&quot;Theft&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Combined output overflow<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2010-5140|CVE-2010-5140]]<br /> | 2010-09-29<br /> | wxBitcoin and bitcoind<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Never confirming transactions<br /> |bgcolor=lime| 100%<br /> |-<br /> | [[#CVE-2011-4447|CVE-2011-4447]]<br /> | 2011-11-11<br /> | wxBitcoin and bitcoind<br /> |bgcolor=pink| Exposure&lt;ref name=&quot;Exposure&quot;&gt;Attacker can access user data outside known acceptable methods&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | Wallet non-encryption<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2011-4447.html 97%]<br /> |-<br /> | [[#CVE-2012-1909|CVE-2012-1909]]<br /> | 2012-03-07<br /> | Bitcoin protocol and all clients<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;&gt;Attacker can create multiple views of the network, enabling [[double-spending]] with over 1 confirmation&lt;/ref&gt;<br /> |bgcolor=lime| Very hard<br /> | Transaction overwriting<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1909.html 88%]<br /> |-<br /> | [[#CVE-2012-1910|CVE-2012-1910]]<br /> | 2012-03-17<br /> | Bitcoin-Qt for Windows<br /> |bgcolor=pink| Unknown&lt;ref name=&quot;Unknown&quot;&gt;Extent of possible abuse is unknown&lt;/ref&gt;<br /> |bgcolor=lime| Hard<br /> | MingW non-multithreading<br /> |bgcolor=lime| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-1910.html 99%]<br /> |-<br /> | [[#BIP-0016|BIP 0016]]<br /> | 2012-04-01<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;&gt;Attacker can double-spend with 1 confirmation&lt;/ref&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory P2SH protocol update<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0016.html 88%]<br /> |-<br /> | [[#CVE-2012-2459|CVE-2012-2459]]<br /> | 2012-05-14<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=pink| Netsplit&lt;ref name=&quot;Netsplit&quot;/&gt;<br /> |bgcolor=pink| Easy<br /> | Block hash collision (via merkle root)<br /> |bgcolor=yellow| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-2459.html 88%]<br /> &lt;!--<br /> |-<br /> | [[#CVE-2012-3584|CVE-2012-3584]]<br /> | 2012-06-16<br /> | Bitcoin p2p protocol<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;/&gt;<br /> | Poor miner incentives<br /> | (no fix)<br /> --&gt;<br /> |-<br /> | [[#CVE-2012-3789|CVE-2012-3789]]<br /> | 2012-06-20<br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | TBD<br /> | TBD<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-3789 74%]<br /> |-<br /> | [[#BIP-0034|BIP 0034]]<br /> | Future<br /> | All Bitcoin clients<br /> |bgcolor=yellow| Fake Conf&lt;ref name=&quot;FakeConf&quot;/&gt;<br /> |bgcolor=yellow| Miners&lt;ref name=&quot;MinerEasy&quot;&gt;Attacking requires mining block(s)&lt;/ref&gt;<br /> | Mandatory block protocol update<br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/BIP-0034.html 47%]<br /> |-<br /> | [[#CVE-2012-4682|CVE-2012-4682]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4682.html 47%]<br /> |-<br /> | [[#CVE-2012-4683|CVE-2012-4683]]<br /> | <br /> | bitcoind and Bitcoin-Qt<br /> |bgcolor=yellow| DoS&lt;ref name=&quot;DoS&quot;/&gt;<br /> | <br /> | <br /> |bgcolor=pink| [http://luke.dashjr.org/programs/bitcoin/files/charts/CVE-2012-4683.html 47%]<br /> |}<br /> <br /> &lt;references/&gt;<br /> <br /> __NOTOC__<br /> <br /> == CVE-2010-5137 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; OP_LSHIFT crash<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5137 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5141 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-28<br /> &lt;b&gt;Summary:&lt;/b&gt; ?<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.4 || 0.3.5<br /> |}<br /> <br /> On July 28 2010, two bugs were discovered and demonstrated on the test network. One exploited a bug in the transaction handling code and allowed an attacker to spend coins that they did not own. This was never exploited on the main network, and was fixed by Bitcoin version 0.3.5.<br /> <br /> After these bugs were discovered, many currently-unused script words were disabled for safety.<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5141 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5138 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-07-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Unlimited SigOp DoS<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.? || 0.3.?<br /> |}<br /> <br /> On July 29 2010, it was discovered that block [http://blockexplorer.com/block/00000000000997f9fd2fe1ee376293ef8c42ad09193a5d2086dddf8e5c426b56 71036] contained several transactions with a ton of OP_CHECKSIG commands. There should only ever be one such command. This caused every node to do extra unnecessary work, and it could have been used as a denial-of-service attack. A new version of Bitcoin was quickly released. The new version did not cause a fork on the main network, though it did cause one on the test network (where someone had played around with the attack more).<br /> <br /> === References ===<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5138 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5139 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-08-15<br /> &lt;b&gt;Summary:&lt;/b&gt; Combined output overflow<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.10 || 0.3.11<br /> |}<br /> <br /> On August 15 2010, it was [http://bitcointalk.org/index.php?topic=822.0 discovered] that block 74638 contained a transaction that created over 184 billion bitcoins for two different addresses. This was possible because the code used for checking transactions before including them in a block didn't account for the case of outputs so large that they overflowed when summed. A new version was published within a few hours of the discovery. The block chain had to be forked. Although many unpatched nodes continued to build on the &quot;bad&quot; block chain, the &quot;good&quot; block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.<br /> <br /> The block and transaction:<br /> &lt;pre&gt;CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,<br /> nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)<br /> CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)<br /> CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)<br /> CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)<br /> CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)<br /> CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)<br /> CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)<br /> vMerkleTree: 012cd8 1d5e51 618eba<br /> <br /> Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c<br /> Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9&lt;/pre&gt;<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=822.0 Discovery]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5139 US-CERT/NIST]<br /> <br /> <br /> == CVE-2010-5140 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2010-09-29<br /> &lt;b&gt;Summary:&lt;/b&gt; Never confirming transactions<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 100%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || * - 0.3.12 || 0.3.13<br /> |}<br /> <br /> Around September 29, 2010, people started [http://www.bitcoin.org/smf/index.php?topic=1306.0 reporting] that their sent transactions would not confirm. This happened because people modified Bitcoin to send sub-0.01 transactions without any fees. A 0.01 fee was at that time required by the network for such transactions (essentially prohibiting them), so the transactions remained at 0 confirmations forever. This became a more serious issue because Bitcoin would send transactions using bitcoins gotten from transactions with 0 confirmations, and these resulting transactions would also never confirm. Because Bitcoin tends to prefer sending smaller coins, these invalid transactions quickly multiplied, contaminating the wallets of everyone who received them.<br /> <br /> Bitcoin was changed to only select coins with at least 1 confirmation. The remaining sub-0.01 transactions were cleared by generators who modified their version of Bitcoin to not require the micropayment fee. It took a while for everything to get cleared, though, because many of the intermediate transactions had been forgotten by the network by this point and had to be rebroadcast by the original senders.<br /> <br /> === References ===<br /> * [http://www.bitcoin.org/smf/index.php?topic=1306.0 Initial reports]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5140 US-CERT/NIST]<br /> <br /> <br /> == CVE-2011-4447 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2011-11-11<br /> &lt;b&gt;Summary:&lt;/b&gt; Wallet non-encryption<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 97%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | bitcoind&lt;br&gt;wxBitcoin || 0.4.0 - 0.4.1rc6 || 0.4.1&lt;br&gt;0.5.0<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=51604.0 Announcement]<br /> * [https://bitcointalk.org/index.php?topic=51474.0 Finding]<br /> * [http://bitcoin.org/releases/2011/11/21/v0.5.0.html 0.5.0]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4447 US-CERT/NIST]<br /> <br /> <br /> == CVE-2012-1909 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-07<br /> &lt;b&gt;Summary:&lt;/b&gt; Transaction overwriting<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin protocol || Before March 15th, 2012 || BIP 30<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4rc2&lt;br&gt;0.5.0rc1 - 0.5.0.4rc2&lt;br&gt;0.5.1rc1 - 0.5.3rc2&lt;br&gt;0.6.0rc1 - 0.6.0rc2 || 0.4.4&lt;br&gt;0.5.0.4&lt;br&gt;0.5.3&lt;br&gt;0.6.0rc3<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=67738.0 Announcement]<br /> * [https://en.bitcoin.it/wiki/BIP_0030 Fix]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=407793 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1909 US-CERT/NIST]<br /> <br /> == CVE-2012-1910 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-03-17<br /> &lt;b&gt;Summary:&lt;/b&gt; MingW non-multithreading<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 99%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt for Windows || 0.5.0rc1 - 0.5.0.4&lt;br&gt;0.5.1rc1 - 0.5.3.0&lt;br&gt;0.6.0rc1 - 0.6.0rc3 || 0.5.0.5&lt;br&gt;0.5.3.1&lt;br&gt;0.5.4&lt;br&gt;0.6.0rc4<br /> |}<br /> <br /> === References ===<br /> * [https://bitcointalk.org/index.php?topic=69120.0 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1910 US-CERT/NIST]<br /> <br /> == BIP-0016 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-04-01<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory P2SH protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.4&lt;br&gt;0.5.0rc1 - 0.5.0.5&lt;br&gt;0.5.1rc1 - 0.5.3&lt;br&gt;0.6.0rc1 || 0.4.5&lt;br&gt;0.5.0.6&lt;br&gt;0.5.4rc1&lt;br&gt;0.6.0rc2<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0016]]<br /> <br /> == CVE-2012-2459 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-05-14<br /> &lt;b&gt;Summary:&lt;/b&gt; Block hash collision (via merkle tree)<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; 88%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.6rc1&lt;br&gt;0.5.0rc1 - 0.5.5rc1&lt;br&gt;0.6.0rc1 - 0.6.0.7rc1&lt;br&gt;0.6.1rc1 - 0.6.1rc1 || 0.4.6&lt;br&gt;0.5.5&lt;br&gt;0.6.0.7&lt;br&gt;0.6.1rc2<br /> |}<br /> <br /> Block hash collisions can easily be made by duplicating transactions in the merkle tree.<br /> Such a collision is invalid, but if recorded (as Bitcoin-Qt and bitcoind prior to 0.6.1 did) would prevent acceptance of the legitimate block with the same hash.<br /> This could be used to fork the blockchain, including deep double-spend attacks.<br /> <br /> === References ===<br /> * [https://bitcointalk.org/?topic=81749 Announcement]<br /> * [https://bugs.gentoo.org/show_bug.cgi?id=415973 Gentoo bug tracker]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2459 US-CERT/NIST]<br /> * [https://bitcointalk.org/?topic=102395 Full Disclosure]<br /> <br /> == CVE-2012-3789 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; 2012-06-20<br /> &lt;b&gt;Summary:&lt;/b&gt; Multiple DoS Vulnerabilties in Satoshi Bitcoin client<br /> &lt;b&gt;Fix Deployment:&lt;/b&gt; &gt;74%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7rc2&lt;br&gt;0.5.0rc1 - 0.5.6rc2&lt;br&gt;0.6.0rc1 - 0.6.0.8rc2&lt;br&gt;0.6.1rc1 - 0.6.2.2 || 0.4.7rc3&lt;br&gt;0.5.6rc3&lt;br&gt;0.6.0.9rc1&lt;br&gt;0.6.3rc1<br /> |}<br /> <br /> === References ===<br /> * [[CVE-2012-3789]]<br /> * [https://bitcointalk.org/?topic=88734 0.6.3rc1 Announcement]<br /> * [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3789 US-CERT/NIST]<br /> <br /> == BIP-0034 ==<br /> <br /> &lt;b&gt;Date:&lt;/b&gt; Future<br /> &lt;b&gt;Summary:&lt;/b&gt; Mandatory block protocol update<br /> &lt;b&gt;Deployment:&lt;/b&gt; 47%<br /> {| class='wikitable'<br /> !colspan='2'| Affected !! Fix<br /> |-<br /> | Bitcoin-Qt&lt;br&gt;bitcoind || * - 0.4.7&lt;br&gt;0.5.0rc1 - 0.5.7&lt;br&gt;0.6.0rc1 - 0.6.0.9&lt;br&gt;0.6.1rc1 - 0.6.3 || 0.4.8rc1&lt;br&gt;0.5.7rc1&lt;br&gt;0.6.0.10rc1&lt;br&gt;0.6.4rc1&lt;br&gt;0.7.0rc1<br /> |-<br /> | wxBitcoin || ALL || NONE<br /> |}<br /> <br /> === References ===<br /> * [[BIP 0034]]<br /> <br /> <br /> ==Definitions==<br /> <br /> A critical vulnerability is one that will have disastrous consequences if it is exploited. A serious vulnerability is one that will have serious consequences if it is exploited&lt;ref&gt;[http://bitcointalk.org/index.php?topic=88892.0 http://bitcointalk.org/index.php?topic=88892.0]&lt;/ref&gt;.<br /> <br /> ==See Also==<br /> <br /> * [[Changelog]]<br /> <br /> ==References==<br /> &lt;references /&gt;<br /> <br /> [[Cateogory:Security]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=33752 2012-12-14T13:46:05Z

<p>Sergio Demian Lerner: /* Security Vulnerabilities and bugs */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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.<br /> 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32600 2012-11-13T19:09:35Z

<p>Sergio Demian Lerner: /* Security Vulnerabilities and bugs */</p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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. 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''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32591 2012-11-13T15:00:55Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Does not forward the same block, transaction or alert twice to the same peer.<br /> # Restricts the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeps a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Bans IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limits the number of stored orphan transactions (10000 by default)<br /> # Uses a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limits the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch all possible errors in transactions before the signature verifications take place, to avoid DoS attacks on CPU usage.<br /> # Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches, when removing an item, evicts a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limits URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> === Security Vulnerabilities and bugs ===<br /> 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. 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 year, without a single vulnerability being exploited ''in the wild''. <br /> See [[Common_Vulnerabilities_and_Exposures]] for a detailed list of vulnerabilities detected and fixed.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32328 2012-11-04T03:41:26Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Restrict the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Permanently ban IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limit the number of stored orphan transactions (10000 by default)<br /> # Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limit the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch errors in transactions before the time consuming signature verifications.<br /> # Penalize peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches: when removing an item, evict a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limit URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32327 2012-11-04T03:40:33Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Restrict the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Permanently ban IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limit the number of stored orphan transactions (10000 by default)<br /> # Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limit the number of stored signatures in the signature cache (50000 signatures by default)<br /> # Tries to catch errors in transactions before the time consuming signature verifications.<br /> # Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches: when removing an item, evict a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limit URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32326 2012-11-04T03:39:23Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Restrict the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Permanently ban IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limit the number of stored orphan transactions (10000 by default)<br /> # Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions<br /> # Limit the number of stored signature in the signature cache (50000 signatures by default)<br /> # Tries to catch errors in transactions before the time consuming signature verifications.<br /> # Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches: when removing an item, evict a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limit URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Weaknesses&diff=32324 2012-11-04T02:57:40Z

<p>Sergio Demian Lerner: </p> <hr /> <div>== Might be a problem ==<br /> === Wallet Vulnerable To Theft ===<br /> <br /> The [[wallet]] is stored unencrypted, by default, and thus becomes a valuable target for theft. Recent releases of the Bitcoin client now supports encryption to protect the wallet data, though the user must opt-in.<br /> <br /> === Tracing a coin's history ===<br /> Tracing a coin's history can be used to connect identities to addresses. [[Anonymity|More info]].<br /> <br /> === Cancer nodes ===<br /> 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.<br /> <br /> 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:<br /> * The attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.<br /> * The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to [[double-spending]] attacks.<br /> * If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.<br /> * 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.<br /> <br /> 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.<br /> <br /> Looking for suspiciously low network hash-rates may help prevent the second one.<br /> <br /> === No authentication for IP transfers ===<br /> Since there's no authentication when sending to an [[IP address]] (as opposed to a [[Address|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. For this reason, IP transfers are disabled by default in modern Bitcoin clients, though the feature can be enabled with a command line argument if desired.<br /> <br /> === Packet sniffing ===<br /> 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.<br /> <br /> === Denial of Service (DoS) attacks ===<br /> 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.<br /> <br /> These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:<br /> <br /> # Does not forward orphan transactions/blocks<br /> # Does not forward double-spend transactions<br /> # Restrict the maximum number of signature checks a transaction input may request<br /> # Continuous rate-limit of free transactions to mitigate 'penny-flooding'<br /> # Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.<br /> # Permanently ban IP addresses that misbehave for a time lapse (24 hours default)<br /> # Limit the number of stored orphan transactions (10000 by default)<br /> # Limit the number of stored signature in the signature cache (50000 signatures by default)<br /> # Tries to catch errors in transactions before the time consuming signature verifications.<br /> # Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.<br /> # In orphan/signature caches: when removing an item, evict a random entry.<br /> # Data structures are specially chosen to avoid loops in which the number of iterations can be controller by an attacker that result in exponential complexity.<br /> # Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.<br /> # In RPC: Only send a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.<br /> # In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.<br /> # In GUI: Limit URI length to prevent a DoS against the QR-Code dialog<br /> <br /> Satoshi client does not directly limit peer bandwidth nor CPU usage.<br /> <br /> === Forcing clock drift against a target node ===<br /> <br /> See [http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html Timejacking] for a description of this attack. It can be fixed by changing how nodes calculate the current time.<br /> <br /> === Illegal content in the block chain ===<br /> It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.<br /> <br /> == Probably not a problem ==<br /> <br /> ===Breaking the cryptography===<br /> 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. [https://bitcointalk.org/index.php?topic=191.msg1585#msg1585 More info].<br /> <br /> ===Scalability===<br /> BitCoin can easily scale beyond the level of traffic VISA sees globally today. See the discussion on the [[scalability]] page for more information.<br /> <br /> ===Segmentation===<br /> If there is even a &quot;trickle&quot; 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. [https://bitcointalk.org/index.php?topic=241.msg2071#msg2071 More info].<br /> <br /> === Attacking all users ===<br /> 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.<br /> <br /> === Dropping transactions ===<br /> Nodes that generate blocks can choose not to include a transaction in their blocks. When this happens, the transaction remains &quot;active&quot; and can be included in a later block. Two things discourage this:<br /> * Nodes only hash a fixed-size ''header'', so there is no speed advantage to dropping transactions.<br /> * [[Satoshi]] has [https://bitcointalk.org/index.php?topic=165.msg1595#msg1595 communicated] that he will write code to stop this kind of thing if it becomes a problem.<br /> <br /> === Attacker has a lot of computing power ===<br /> 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:<br /> * Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack|double-spend transactions]] that previously had already been seen in the block chain.<br /> * Prevent some or all transactions from gaining any confirmations<br /> * Prevent some or all other miners from mining any valid blocks<br /> The attacker ''can't'':<br /> * Reverse other people's transactions<br /> * Prevent transactions from being sent at all (they'll show as 0/unconfirmed)<br /> * Change the number of coins generated per block<br /> * Create coins out of thin air<br /> * Send coins that never belonged to him<br /> <br /> 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.<br /> <br /> 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 &quot;untangle&quot; the mess created -- any changes the attacker makes might become permanent.<br /> <br /> === Spamming transactions ===<br /> <br /> 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.<br /> <br /> This is made expensive by the [[transaction fee|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.<br /> <br /> === The [[Double-spending#Finney_attack|Finney attack]] ===<br /> Named for Hal Finney, who first described this variation of a double-spend attack involving accepting [http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 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.<br /> <br /> ===Rival/malicious client code===<br /> 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.<br /> <br /> == Definitely not a problem ==<br /> <br /> ===Coin destruction===<br /> 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.<br /> <br /> 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.<br /> <br /> ===Generating tons of addresses===<br /> Generating an address doesn't touch the network at all. You'd only be wasting your CPU resources and disk space.<br /> <br /> Also, a collision is highly unlikely.<br /> <br /> Keys are 256 bit in length and are hashed in a 160 bit address.(2^160th power)<br /> 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.15 x 10^38)[http://www.wolframalpha.com/input/?i=2^160+%2F+world+population]<br /> <br /> ===Everyone calculates at the same rate===<br /> 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 &quot;Merkle tree&quot; hash of this is part of the block header.<br /> <br /> So everyone begins with slightly different blocks and everyone truly has a random chance of winning (modified by CPU power).<br /> <br /> ===Generate &quot;valid&quot; blocks with a lower difficulty than normal===<br /> 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 &quot;false&quot; chain would be destroyed in the process).<br /> <br /> * Even though your network's difficulty can be less than the real difficulty, this doesn't give you any advantage over the real network. You'll gain ground when the real network is taking more than 10 minutes to generate a block, but you'll lose ground when the network takes less than 10 minutes.<br /> * Every few releases of Bitcoin, a recent block hash is hardcoded into the source code. Any blocks before that point can't be changed. An attacker starting at that point would have to reduce the difficulty, but this would require him to generate blocks at a much slower rate than once per 10 minutes. By the time he finally gets to a difficulty of 1, a new version of Bitcoin with an updated hardcoded block will probably have been released.<br /> * &quot;Block chain length&quot; 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 CPU usage will win.<br /> <br /> ==See Also==<br /> <br /> * [[Double-spending]]<br /> <br /> [[Category:Technical]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Talk:Common_Vulnerabilities_and_Exposures&diff=32323 2012-11-04T01:56:27Z

<p>Sergio Demian Lerner: Created page with &quot;Who is updating the vulnerable percentages? Currently they are outdated.&quot;</p> <hr /> <div>Who is updating the vulnerable percentages? Currently they are outdated.</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Protocol_documentation&diff=31425 2012-10-02T16:34:52Z

<p>Sergio Demian Lerner: </p> <hr /> <div>Sources:<br /> * [[Original Bitcoin client]] source<br /> <br /> Type names used in this documentation are from the C99 standard.<br /> <br /> For protocol used in mining, see [[Getwork]].<br /> <br /> ==Common standards==<br /> <br /> === Hashes ===<br /> <br /> Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br /> <br /> Example of double-SHA-256 encoding of string &quot;hello&quot;:<br /> <br /> hello<br /> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br /> 9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br /> <br /> For bitcoin addresses (RIPEMD-160) this would give:<br /> <br /> hello<br /> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br /> b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br /> <br /> === Merkle Trees ===<br /> <br /> Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:<br /> <br /> hash(a) = sha256(sha256(a))<br /> <br /> hash(a) hash(b) hash(c)<br /> hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br /> hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br /> <br /> They are paired up, with the last element being _duplicated_.<br /> <br /> Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br /> <br /> === Signatures ===<br /> <br /> Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br /> <br /> For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br /> <br /> Public keys (in scripts) are given as 04 &lt;x&gt; &lt;y&gt; where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as &lt;sign&gt; &lt;x&gt; where &lt;sign&gt; is 0x02 if ''y'' is even and 0x03 if ''y'' is odd. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br /> <br /> === Transaction Verification ===<br /> Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br /> <br /> Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br /> <br /> Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br /> <br /> In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br /> <br /> A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br /> <br /> Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br /> <br /> === Addresses ===<br /> <br /> A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br /> <br /> Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br /> Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br /> Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br /> Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br /> <br /> The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br /> <br /> == Common structures ==<br /> <br /> Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br /> <br /> === Message structure ===<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br /> |-<br /> | 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br /> |-<br /> | 4 || length || uint32_t || Length of payload in number of bytes<br /> |-<br /> | 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br /> |-<br /> | ? || payload || uchar[] || The actual data<br /> |}<br /> <br /> <br /> Known magic values:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Network !! Magic value !! Sent over wire as<br /> |-<br /> | main || 0xD9B4BEF9 || F9 BE B4 D9<br /> |-<br /> | testnet || 0xDAB5BFFA || FA BF B5 DA<br /> |}<br /> <br /> === Variable length integer ===<br /> <br /> Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Storage length !! Format<br /> |-<br /> | &lt; 0xfd || 1 || uint8_t<br /> |-<br /> | &lt;= 0xffff || 3 || 0xfd followed by the length as uint16_t<br /> |-<br /> | &lt;= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br /> |-<br /> | - || 9 || 0xff followed by the length as uint64_t<br /> |}<br /> <br /> === Variable length string ===<br /> <br /> Variable length string can be stored using a variable length integer followed by the string itself.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br /> |-<br /> | ? || string || char[] || The string itself (can be empty)<br /> |}<br /> <br /> === Network address ===<br /> <br /> When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || time || uint32 || the Time (version &gt;= 31402)<br /> |-<br /> | 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br /> |-<br /> | 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br /> (12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br /> |-<br /> | 2 || port || uint16_t || port number, network byte order<br /> |}<br /> <br /> Hexdump example of Network address structure<br /> <br /> &lt;pre&gt;<br /> 0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br /> <br /> Network address:<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br /> 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br /> 20 8D - Port 8333<br /> &lt;/pre&gt;<br /> <br /> === Inventory Vectors ===<br /> <br /> Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br /> <br /> Inventory vectors consist of the following data format:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || type || uint32_t || Identifies the object type linked to this inventory<br /> |-<br /> | 32 || hash || char[32] || Hash of the object<br /> |}<br /> <br /> <br /> The object type is currently defined as one of the following possibilities:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 0 || ERROR || Any data of with this number may be ignored<br /> |-<br /> | 1 || MSG_TX || Hash is related to a transaction<br /> |-<br /> | 2 || MSG_BLOCK || Hash is related to a data block<br /> |}<br /> <br /> Other Data Type values are considered reserved for future implementations.<br /> <br /> === Block Headers ===<br /> <br /> Block headers are sent in a headers packet in response to a getheaders message.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Block version information, based upon the software version creating this block<br /> |-<br /> | 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br /> |-<br /> | 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br /> |-<br /> | 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br /> |-<br /> | 4 || bits || uint32_t || The calculated difficulty target being used for this block<br /> |-<br /> | 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br /> |-<br /> | 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br /> |}<br /> <br /> == Message types ==<br /> <br /> === version ===<br /> <br /> When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || int32_t || Identifies protocol version being used by the node<br /> |-<br /> | 8 || services || uint64_t || bitfield of features to be enabled for this connection<br /> |-<br /> | 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br /> |-<br /> | 26 || addr_recv || net_addr || The network address of the node receiving this message<br /> |-<br /> |colspan=&quot;4&quot;| version &gt;= 106<br /> |-<br /> | 26 || addr_from || net_addr || The network address of the node emitting this message<br /> |-<br /> | 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br /> |-<br /> | ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br /> |-<br /> | 4 || start_height || int32_t || The last block received by the emitting node<br /> |}<br /> <br /> A &quot;verack&quot; packet shall be sent if the version packet was accepted.<br /> <br /> The following services are currently assigned:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br /> |}<br /> <br /> Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br /> 0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br /> 0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br /> 0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br /> 0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br /> 0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br /> <br /> Message header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 76 65 72 73 69 6F 6E 00 00 00 00 00 - &quot;version&quot; command<br /> 55 00 00 00 - Payload is 85 bytes long<br /> - No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br /> Version message:<br /> 9C 7C 00 00 - 31900 (version 0.3.19)<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br /> E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br /> DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br /> 00 - &quot;&quot; sub-version string (string is 0 bytes long)<br /> 55 81 01 00 - Last block sending node has is block #98645<br /> &lt;/pre&gt;<br /> <br /> === verack ===<br /> <br /> The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string &quot;verack&quot;.<br /> <br /> Hexdump of the verack message:<br /> <br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br /> 0010 00 00 00 00 5D F6 E0 E2 ........<br /> <br /> Message header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 76 65 72 61 63 6B 00 00 00 00 00 00 - &quot;verack&quot; command<br /> 00 00 00 00 - Payload is 0 bytes long<br /> 5D F6 E0 E2 - Checksum<br /> &lt;/pre&gt;<br /> <br /> === addr ===<br /> <br /> Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br /> <br /> Payload:<br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br /> |-<br /> | 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version &lt; 209 will only read the first one. The uint32_t is a timestamp (see note below).<br /> |}<br /> <br /> '''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br /> <br /> Hexdump example of ''addr'' message:<br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br /> 0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br /> 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br /> 0030 FF 0A 00 00 01 20 8D ..... .<br /> <br /> Message Header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 61 64 64 72 00 00 00 00 00 00 00 00 - &quot;addr&quot;<br /> 1F 00 00 00 - payload is 31 bytes long<br /> ED 52 39 9B - checksum of payload<br /> <br /> Payload:<br /> 01 - 1 address in this message<br /> <br /> Address:<br /> E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is &gt;= 31402)<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br /> 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br /> 20 8D - port 8333<br /> &lt;/pre&gt;<br /> <br /> === inv ===<br /> <br /> Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br /> <br /> Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br /> |-<br /> | 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br /> |}<br /> <br /> === getdata ===<br /> <br /> getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.<br /> <br /> Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br /> |-<br /> | 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br /> |}<br /> <br /> === getblocks ===<br /> <br /> Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || the protocol version<br /> |-<br /> | 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br /> |-<br /> | 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br /> |-<br /> | 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br /> |}<br /> <br /> To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br /> <br /> &lt;pre&gt;<br /> // From libbitcoin which is under AGPL<br /> std::vector&lt;size_t&gt; block_locator_indices(int top_depth)<br /> {<br /> // Start at max_depth<br /> std::vector&lt;size_t&gt; indices;<br /> // Push last 10 indices first<br /> size_t step = 1, start = 0;<br /> for (int i = top_depth; i &gt; 0; i -= step, ++start)<br /> {<br /> if (start &gt;= 10)<br /> step *= 2;<br /> indices.push_back(i);<br /> }<br /> indices.push_back(0);<br /> return indices;<br /> }<br /> &lt;/pre&gt;<br /> <br /> Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br /> <br /> === getheaders ===<br /> <br /> Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || the protocol version<br /> |-<br /> | 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br /> |-<br /> | 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br /> |-<br /> | 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br /> |}<br /> <br /> For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#Variable_length_integer|getblocks]] packet.<br /> <br /> === tx ===<br /> <br /> ''tx'' describes a bitcoin transaction, in reply to ''getdata''<br /> <br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Transaction data format version<br /> |-<br /> | 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br /> |-<br /> | 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br /> |-<br /> | 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br /> |-<br /> | 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br /> |-<br /> | 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Description<br /> |-<br /> | 0 || Always locked<br /> |-<br /> | &lt; 500000000 || Block number at which this transaction is locked<br /> |-<br /> | &gt;= 500000000 || UNIX timestamp at which this transaction is locked<br /> |}<br /> A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).<br /> <br /> |}<br /> <br /> TxIn consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br /> |-<br /> | 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br /> |-<br /> | ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br /> |-<br /> | 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for &quot;replacement&quot; of transactions when information is updated before inclusion into a block.<br /> |}<br /> <br /> The OutPoint structure consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 32 || hash || char[32] || The hash of the referenced transaction.<br /> |-<br /> | 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br /> |}<br /> <br /> The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br /> <br /> (Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br /> <br /> The TxOut structure consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 8 || value || int64_t || Transaction Value<br /> |-<br /> | 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br /> |-<br /> | ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br /> |}<br /> <br /> Example ''tx'' message:<br /> &lt;pre&gt;<br /> 000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br /> 000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br /> 000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br /> 000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br /> 000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br /> 000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br /> 000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br /> 000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br /> 000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br /> 000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br /> 0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br /> 0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br /> 0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br /> 0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br /> 0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br /> 0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 &quot;^...........v..<br /> 000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br /> 000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br /> <br /> <br /> Message header:<br /> F9 BE B4 D9 - main network magic bytes<br /> 74 78 00 00 00 00 00 00 00 00 00 00 - &quot;tx&quot; command<br /> 02 01 00 00 - payload is 258 bytes long<br /> E2 93 CD BE - checksum of payload<br /> <br /> Transaction:<br /> 01 00 00 00 - version<br /> <br /> Inputs:<br /> 01 - number of transaction inputs<br /> <br /> Input 1:<br /> 6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br /> 12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br /> 00 00 00 00<br /> <br /> 8B - script is 139 bytes long<br /> <br /> 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br /> 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br /> 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br /> 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br /> 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br /> F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br /> 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br /> 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br /> 2F 46 61 4A 4C 70 C0 F1 4B EF F5<br /> <br /> FF FF FF FF - sequence<br /> <br /> Outputs:<br /> 02 - 2 Output Transactions<br /> <br /> Output 1:<br /> 40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br /> 19 - pk_script is 25 bytes long<br /> <br /> 76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br /> A9 D9 EA 1A FB 22 5E 88 AC<br /> <br /> Output 2:<br /> 80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br /> 19 - pk_script is 25 bytes long<br /> <br /> 76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br /> FD A0 B7 8B 4E CC 52 88 AC<br /> <br /> Locktime:<br /> 00 00 00 00 - lock time<br /> &lt;/pre&gt;<br /> <br /> === block ===<br /> <br /> The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Block version information, based upon the software version creating this block<br /> |-<br /> | 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br /> |-<br /> | 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br /> |-<br /> | 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br /> |-<br /> | 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br /> |-<br /> | 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br /> |-<br /> | ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br /> |-<br /> | ? || txns || tx[] || Block transactions, in format of &quot;tx&quot; command<br /> |}<br /> <br /> The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br /> See [[Block hashing algorithm]] for details and an example.<br /> <br /> === headers ===<br /> <br /> The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br /> |-<br /> | 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br /> |}<br /> <br /> Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br /> <br /> === getaddr ===<br /> <br /> The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br /> <br /> No additional data is transmitted with this message.<br /> <br /> === checkorder ===<br /> <br /> This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br /> <br /> It contains a CWalletTx object<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> |colspan=&quot;4&quot;| Fields from CMerkleTx<br /> |-<br /> | ? || hashBlock<br /> |-<br /> | ? || vMerkleBranch<br /> |-<br /> | ? || nIndex<br /> |-<br /> |colspan=&quot;4&quot;| Fields from CWalletTx<br /> |-<br /> | ? || vtxPrev<br /> |-<br /> | ? || mapValue<br /> |-<br /> | ? || vOrderForm<br /> |-<br /> | ? || fTimeReceivedIsTxTime<br /> |-<br /> | ? || nTimeReceived<br /> |-<br /> | ? || fFromMe<br /> |-<br /> | ? || fSpent<br /> |}<br /> <br /> === submitorder ===<br /> <br /> Confirms an order has been submitted. <br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 32 || hash || char[32] || Hash of the transaction<br /> |-<br /> | ? || wallet_entry || CWalletTx || Same payload as checkorder<br /> |}<br /> <br /> === reply ===<br /> <br /> Generic reply for [[IP Transactions]]<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || reply || uint32_t || reply code<br /> |}<br /> <br /> Possible values:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br /> |-<br /> | 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br /> |-<br /> | 2 || DENIED || IP Transactions are not accepted by this node<br /> |}<br /> <br /> === ping ===<br /> <br /> The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br /> <br /> === alert ===<br /> <br /> An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br /> <br /> Alert format:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || payload || var_str || Serialized alert payload<br /> |-<br /> | ? || signature || var_str || An ECDSA signature of the message<br /> |}<br /> <br /> The developers of Satoshi's client use this public key for signing alerts:<br /> 04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br /> (hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br /> <br /> The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || Version || int32_t || Alert format version<br /> |-<br /> | 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br /> |-<br /> | 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br /> |-<br /> | 4 || ID || int32_t || A unique ID number for this alert<br /> |-<br /> | 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br /> |-<br /> | ? || setCancel || set&lt;int&gt; || All alert IDs contained in this set should be canceled as above<br /> |-<br /> | 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br /> |-<br /> | 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br /> |-<br /> | ? || setSubVer || set&lt;string&gt; || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br /> |-<br /> | 4 || Priority || int32_t || Relative priority compared to other alerts<br /> |-<br /> | ? || Comment || string || A comment on the alert that is not displayed<br /> |-<br /> | ? || StatusBar || string || The alert message that is displayed to the user<br /> |-<br /> | ? || Reserved || string || Reserved<br /> |}<br /> <br /> Sample alert (no message header):<br /> 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br /> 0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br /> 76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br /> 79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br /> 53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br /> <br /> Version: 1<br /> RelayUntil: 1329620535<br /> Expiration: 1329792435<br /> ID: 1010<br /> Cancel: 1009<br /> setCancel: &lt;empty&gt;<br /> MinVer: 10000<br /> MaxVer: 61000<br /> setSubVer: &lt;empty&gt;<br /> Priority: 100<br /> Comment: &lt;empty&gt;<br /> StatusBar: &quot;See bitcoin.org/feb20 if you have trouble connecting after 20 February&quot;<br /> Reserved: &lt;empty&gt;<br /> <br /> == Scripting ==<br /> <br /> See [[script]].<br /> <br /> == Wireshark dissector ==<br /> A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br /> <br /> ==See Also==<br /> <br /> * [[Network]]<br /> * [[Protocol rules]]<br /> [[zh-cn:协议说明]]<br /> [[Category:Technical]]<br /> [[Category:Developer]]</div>

Sergio Demian Lerner https://en.bitcoin.it/w/index.php?title=Protocol_documentation&diff=31424 2012-10-02T16:31:05Z

<p>Sergio Demian Lerner: </p> <hr /> <div>Sources:<br /> * [[Original Bitcoin client]] source<br /> <br /> Type names used in this documentation are from the C99 standard.<br /> <br /> For protocol used in mining, see [[Getwork]].<br /> <br /> ==Common standards==<br /> <br /> === Hashes ===<br /> <br /> Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br /> <br /> Example of double-SHA-256 encoding of string &quot;hello&quot;:<br /> <br /> hello<br /> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br /> 9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br /> <br /> For bitcoin addresses (RIPEMD-160) this would give:<br /> <br /> hello<br /> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br /> b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br /> <br /> === Merkle Trees ===<br /> <br /> Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:<br /> <br /> hash(a) = sha256(sha256(a))<br /> <br /> hash(a) hash(b) hash(c)<br /> hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br /> hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br /> <br /> They are paired up, with the last element being _duplicated_.<br /> <br /> Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br /> <br /> === Signatures ===<br /> <br /> Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br /> <br /> For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br /> <br /> Public keys (in scripts) are given as 04 &lt;x&gt; &lt;y&gt; where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as &lt;sign&gt; &lt;x&gt; where &lt;sign&gt; is 0x02 if ''y'' is even and 0x03 if ''y'' is odd. Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br /> <br /> === Transaction Verification ===<br /> Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br /> <br /> Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br /> <br /> Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br /> <br /> In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br /> <br /> A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br /> <br /> Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br /> <br /> === Addresses ===<br /> <br /> A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br /> <br /> Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br /> Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br /> Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br /> Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br /> <br /> The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br /> <br /> == Common structures ==<br /> <br /> Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br /> <br /> === Message structure ===<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br /> |-<br /> | 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br /> |-<br /> | 4 || length || uint32_t || Length of payload in number of bytes<br /> |-<br /> | 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br /> |-<br /> | ? || payload || uchar[] || The actual data<br /> |}<br /> <br /> <br /> Known magic values:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Network !! Magic value !! Sent over wire as<br /> |-<br /> | main || 0xD9B4BEF9 || F9 BE B4 D9<br /> |-<br /> | testnet || 0xDAB5BFFA || FA BF B5 DA<br /> |}<br /> <br /> === Variable length integer ===<br /> <br /> Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Storage length !! Format<br /> |-<br /> | &lt; 0xfd || 1 || uint8_t<br /> |-<br /> | &lt;= 0xffff || 3 || 0xfd followed by the length as uint16_t<br /> |-<br /> | &lt;= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br /> |-<br /> | - || 9 || 0xff followed by the length as uint64_t<br /> |}<br /> <br /> === Variable length string ===<br /> <br /> Variable length string can be stored using a variable length integer followed by the string itself.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br /> |-<br /> | ? || string || char[] || The string itself (can be empty)<br /> |}<br /> <br /> === Network address ===<br /> <br /> When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || time || uint32 || the Time (version &gt;= 31402)<br /> |-<br /> | 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br /> |-<br /> | 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br /> (12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br /> |-<br /> | 2 || port || uint16_t || port number, network byte order<br /> |}<br /> <br /> Hexdump example of Network address structure<br /> <br /> &lt;pre&gt;<br /> 0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br /> <br /> Network address:<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br /> 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br /> 20 8D - Port 8333<br /> &lt;/pre&gt;<br /> <br /> === Inventory Vectors ===<br /> <br /> Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br /> <br /> Inventory vectors consist of the following data format:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || type || uint32_t || Identifies the object type linked to this inventory<br /> |-<br /> | 32 || hash || char[32] || Hash of the object<br /> |}<br /> <br /> <br /> The object type is currently defined as one of the following possibilities:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 0 || ERROR || Any data of with this number may be ignored<br /> |-<br /> | 1 || MSG_TX || Hash is related to a transaction<br /> |-<br /> | 2 || MSG_BLOCK || Hash is related to a data block<br /> |}<br /> <br /> Other Data Type values are considered reserved for future implementations.<br /> <br /> === Block Headers ===<br /> <br /> Block headers are sent in a headers packet in response to a getheaders message.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Block version information, based upon the software version creating this block<br /> |-<br /> | 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br /> |-<br /> | 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br /> |-<br /> | 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br /> |-<br /> | 4 || bits || uint32_t || The calculated difficulty target being used for this block<br /> |-<br /> | 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br /> |-<br /> | 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br /> |}<br /> <br /> == Message types ==<br /> <br /> === version ===<br /> <br /> When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || int32_t || Identifies protocol version being used by the node<br /> |-<br /> | 8 || services || uint64_t || bitfield of features to be enabled for this connection<br /> |-<br /> | 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br /> |-<br /> | 26 || addr_recv || net_addr || The network address of the node receiving this message<br /> |-<br /> |colspan=&quot;4&quot;| version &gt;= 106<br /> |-<br /> | 26 || addr_from || net_addr || The network address of the node emitting this message<br /> |-<br /> | 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br /> |-<br /> | ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br /> |-<br /> | 4 || start_height || int32_t || The last block received by the emitting node<br /> |}<br /> <br /> A &quot;verack&quot; packet shall be sent if the version packet was accepted.<br /> <br /> The following services are currently assigned:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br /> |}<br /> <br /> Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br /> 0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br /> 0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br /> 0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br /> 0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br /> 0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br /> <br /> Message header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 76 65 72 73 69 6F 6E 00 00 00 00 00 - &quot;version&quot; command<br /> 55 00 00 00 - Payload is 85 bytes long<br /> - No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br /> Version message:<br /> 9C 7C 00 00 - 31900 (version 0.3.19)<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br /> E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br /> DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br /> 00 - &quot;&quot; sub-version string (string is 0 bytes long)<br /> 55 81 01 00 - Last block sending node has is block #98645<br /> &lt;/pre&gt;<br /> <br /> === verack ===<br /> <br /> The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string &quot;verack&quot;.<br /> <br /> Hexdump of the verack message:<br /> <br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br /> 0010 00 00 00 00 5D F6 E0 E2 ........<br /> <br /> Message header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 76 65 72 61 63 6B 00 00 00 00 00 00 - &quot;verack&quot; command<br /> 00 00 00 00 - Payload is 0 bytes long<br /> 5D F6 E0 E2 - Checksum<br /> &lt;/pre&gt;<br /> <br /> === addr ===<br /> <br /> Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br /> <br /> Payload:<br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br /> |-<br /> | 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version &lt; 209 will only read the first one. The uint32_t is a timestamp (see note below).<br /> |}<br /> <br /> '''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br /> <br /> Hexdump example of ''addr'' message:<br /> &lt;pre&gt;<br /> 0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br /> 0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br /> 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br /> 0030 FF 0A 00 00 01 20 8D ..... .<br /> <br /> Message Header:<br /> F9 BE B4 D9 - Main network magic bytes<br /> 61 64 64 72 00 00 00 00 00 00 00 00 - &quot;addr&quot;<br /> 1F 00 00 00 - payload is 31 bytes long<br /> ED 52 39 9B - checksum of payload<br /> <br /> Payload:<br /> 01 - 1 address in this message<br /> <br /> Address:<br /> E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is &gt;= 31402)<br /> 01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br /> 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br /> 20 8D - port 8333<br /> &lt;/pre&gt;<br /> <br /> === inv ===<br /> <br /> Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br /> <br /> Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br /> |-<br /> | 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br /> |}<br /> <br /> === getdata ===<br /> <br /> getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements.<br /> <br /> Payload (maximum payload length: 50000 bytes):<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br /> |-<br /> | 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br /> |}<br /> <br /> === getblocks ===<br /> <br /> Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || the protocol version<br /> |-<br /> | 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br /> |-<br /> | 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br /> |-<br /> | 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br /> |}<br /> <br /> To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br /> <br /> &lt;pre&gt;<br /> // From libbitcoin which is under AGPL<br /> std::vector&lt;size_t&gt; block_locator_indices(int top_depth)<br /> {<br /> // Start at max_depth<br /> std::vector&lt;size_t&gt; indices;<br /> // Push last 10 indices first<br /> size_t step = 1, start = 0;<br /> for (int i = top_depth; i &gt; 0; i -= step, ++start)<br /> {<br /> if (start &gt;= 10)<br /> step *= 2;<br /> indices.push_back(i);<br /> }<br /> indices.push_back(0);<br /> return indices;<br /> }<br /> &lt;/pre&gt;<br /> <br /> Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br /> <br /> === getheaders ===<br /> <br /> Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || the protocol version<br /> |-<br /> | 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br /> |-<br /> | 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br /> |-<br /> | 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br /> |}<br /> <br /> For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#Variable_length_integer|getblocks]] packet.<br /> <br /> === tx ===<br /> <br /> ''tx'' describes a bitcoin transaction, in reply to ''getdata''<br /> <br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Transaction data format version<br /> |-<br /> | 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br /> |-<br /> | 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br /> |-<br /> | 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br /> |-<br /> | 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br /> |-<br /> | 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Description<br /> |-<br /> | 0 || Always locked<br /> |-<br /> | &lt; 500000000 || Block number at which this transaction is locked<br /> |-<br /> | &gt;= 500000000 || UNIX timestamp at which this transaction is locked<br /> |}<br /> A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired (replacement is currently disabled in Bitcoin, however, so this is useless).<br /> <br /> |}<br /> <br /> TxIn consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br /> |-<br /> | 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br /> |-<br /> | ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br /> |-<br /> | 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for &quot;replacement&quot; of transactions when information is updated before inclusion into a block.<br /> |}<br /> <br /> The OutPoint structure consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 32 || hash || char[32] || The hash of the referenced transaction.<br /> |-<br /> | 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br /> |}<br /> <br /> The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br /> <br /> (Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br /> <br /> The TxOut structure consists of the following fields:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 8 || value || int64_t || Transaction Value<br /> |-<br /> | 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br /> |-<br /> | ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br /> |}<br /> <br /> Example ''tx'' message:<br /> &lt;pre&gt;<br /> 000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br /> 000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br /> 000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br /> 000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br /> 000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br /> 000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br /> 000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br /> 000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br /> 000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br /> 000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br /> 0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br /> 0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br /> 0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br /> 0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br /> 0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br /> 0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 &quot;^...........v..<br /> 000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br /> 000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br /> <br /> <br /> Message header:<br /> F9 BE B4 D9 - main network magic bytes<br /> 74 78 00 00 00 00 00 00 00 00 00 00 - &quot;tx&quot; command<br /> 02 01 00 00 - payload is 258 bytes long<br /> E2 93 CD BE - checksum of payload<br /> <br /> Transaction:<br /> 01 00 00 00 - version<br /> <br /> Inputs:<br /> 01 - number of transaction inputs<br /> <br /> Input 1:<br /> 6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br /> 12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br /> 00 00 00 00<br /> <br /> 8B - script is 139 bytes long<br /> <br /> 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br /> 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br /> 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br /> 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br /> 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br /> F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br /> 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br /> 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br /> 2F 46 61 4A 4C 70 C0 F1 4B EF F5<br /> <br /> FF FF FF FF - sequence<br /> <br /> Outputs:<br /> 02 - 2 Output Transactions<br /> <br /> Output 1:<br /> 40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br /> 19 - pk_script is 25 bytes long<br /> <br /> 76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br /> A9 D9 EA 1A FB 22 5E 88 AC<br /> <br /> Output 2:<br /> 80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br /> 19 - pk_script is 25 bytes long<br /> <br /> 76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br /> FD A0 B7 8B 4E CC 52 88 AC<br /> <br /> Locktime:<br /> 00 00 00 00 - lock time<br /> &lt;/pre&gt;<br /> <br /> === block ===<br /> <br /> The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || version || uint32_t || Block version information, based upon the software version creating this block<br /> |-<br /> | 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br /> |-<br /> | 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br /> |-<br /> | 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br /> |-<br /> | 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br /> |-<br /> | 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br /> |-<br /> | ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br /> |-<br /> | ? || txns || tx[] || Block transactions, in format of &quot;tx&quot; command<br /> |}<br /> <br /> The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br /> See [[Block hashing algorithm]] for details and an example.<br /> <br /> === headers ===<br /> <br /> The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br /> |-<br /> | 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br /> |}<br /> <br /> Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br /> <br /> === getaddr ===<br /> <br /> The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br /> <br /> No additional data is transmitted with this message.<br /> <br /> === checkorder ===<br /> <br /> This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br /> <br /> It contains a CWalletTx object<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> |colspan=&quot;4&quot;| Fields from CMerkleTx<br /> |-<br /> | ? || hashBlock<br /> |-<br /> | ? || vMerkleBranch<br /> |-<br /> | ? || nIndex<br /> |-<br /> |colspan=&quot;4&quot;| Fields from CWalletTx<br /> |-<br /> | ? || vtxPrev<br /> |-<br /> | ? || mapValue<br /> |-<br /> | ? || vOrderForm<br /> |-<br /> | ? || fTimeReceivedIsTxTime<br /> |-<br /> | ? || nTimeReceived<br /> |-<br /> | ? || fFromMe<br /> |-<br /> | ? || fSpent<br /> |}<br /> <br /> === submitorder ===<br /> <br /> Confirms an order has been submitted. <br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 32 || hash || char[32] || Hash of the transaction<br /> |-<br /> | ? || wallet_entry || CWalletTx || Same payload as checkorder<br /> |}<br /> <br /> === reply ===<br /> <br /> Generic reply for [[IP Transactions]]<br /> <br /> Payload:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || reply || uint32_t || reply code<br /> |}<br /> <br /> Possible values:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Value !! Name !! Description<br /> |-<br /> | 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br /> |-<br /> | 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br /> |-<br /> | 2 || DENIED || IP Transactions are not accepted by this node<br /> |}<br /> <br /> === ping ===<br /> <br /> The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br /> <br /> === alert ===<br /> <br /> An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br /> <br /> Alert format:<br /> <br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | ? || payload || var_str || Serialized alert payload<br /> |-<br /> | ? || signature || var_str || An ECDSA signature of the message<br /> |}<br /> <br /> The developers of Satoshi's client use this public key for signing alerts:<br /> 04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br /> (hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br /> <br /> The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br /> {|class=&quot;wikitable&quot;<br /> ! Field Size !! Description !! Data type !! Comments<br /> |-<br /> | 4 || Version || int32_t || Alert format version<br /> |-<br /> | 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br /> |-<br /> | 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br /> |-<br /> | 4 || ID || int32_t || A unique ID number for this alert<br /> |-<br /> | 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br /> |-<br /> | ? || setCancel || set&lt;int&gt; || All alert IDs contained in this set should be canceled as above<br /> |-<br /> | 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br /> |-<br /> | 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br /> |-<br /> | ? || setSubVer || set&lt;string&gt; || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br /> |-<br /> | 4 || Priority || int32_t || Relative priority compared to other alerts<br /> |-<br /> | ? || Comment || string || A comment on the alert that is not displayed<br /> |-<br /> | ? || StatusBar || string || The alert message that is displayed to the user<br /> |-<br /> | ? || Reserved || string || Reserved<br /> |}<br /> <br /> Sample alert (no message header):<br /> 73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br /> 0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br /> 76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br /> 79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br /> 53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br /> <br /> Version: 1<br /> RelayUntil: 1329620535<br /> Expiration: 1329792435<br /> ID: 1010<br /> Cancel: 1009<br /> setCancel: &lt;empty&gt;<br /> MinVer: 10000<br /> MaxVer: 61000<br /> setSubVer: &lt;empty&gt;<br /> Priority: 100<br /> Comment: &lt;empty&gt;<br /> StatusBar: &quot;See bitcoin.org/feb20 if you have trouble connecting after 20 February&quot;<br /> Reserved: &lt;empty&gt;<br /> <br /> == Scripting ==<br /> <br /> See [[script]].<br /> <br /> == Wireshark dissector ==<br /> A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br /> <br /> ==See Also==<br /> <br /> * [[Network]]<br /> * [[Protocol rules]]<br /> [[zh-cn:协议说明]]<br /> [[Category:Technical]]<br /> [[Category:Developer]]</div>

Sergio Demian Lerner