Incidents - Revision history

Luke-jr: Superceded by CVEs page

2012-05-30T00:27:02Z

Superceded by CVEs page

← Older revision		Revision as of 00:27, 30 May 2012
Line 1:		Line 1:
	~~Incidents in which a problem with the protocol was discovered or where the client mishandled the protocol, either of which were newsworthy or resolution required updated client software.~~		#Redirect [[Common Vulnerabilities and Exposures]]

	~~== LSHIFT and RETURN bugs ==~~

	On July 28 2010 two bugs were discovered and demonstrated on the test network. The first caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. The second exploited another bug in the transaction handling code and allowed an attacker to spend coins that they did not own. Neither were exploited on the main network, and both were fixed by Bitcoin version 0.3.5.

	~~After these bugs were discovered, many currently-unused [[script]] words were disabled for safety.~~

	~~== OP_CHECKSIG abuse ==~~

	~~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).

	~~== Value overflow ==~~

	~~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 "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.

	~~The block~~ and ~~transaction:~~
	~~<pre>CBlock(hash=0000000000790ab3, ver=1, hashPrevBlock=0000000000606865, hashMerkleRoot=618eba,~~
	~~nTime=1281891957, nBits=1c00800e, nNonce=28192719, vtx=2)~~
	~~CTransaction(hash=012cd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)~~
	~~CTxIn(COutPoint(000000, -1), coinbase 040e80001c028f00)~~
	~~CTxOut(nValue=50.51000000, scriptPubKey=0x4F4BA55D1580F8C3A8A2C7)~~
	~~CTransaction(hash=1d5e51, ver=1, vin.size=1, vout.size=2, nLockTime=0)~~
	~~CTxIn(COutPoint(237fe8, 0), scriptSig=0xA87C02384E1F184B79C6AC)~~
	~~CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0xB7A7)~~
	~~CTxOut(nValue=92233720368.54275808, scriptPubKey=OP_DUP OP_HASH160 0x1512)~~
	~~vMerkleTree: 012cd8 1d5e51 618eba~~

	~~Block hash: 0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c~~
	~~Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9</pre>~~

	~~== Micropayment contamination ==~~

	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.

	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.

	~~== ASCII embedding into blockchain ==~~

	Occurred July 30, 2011. Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block which included a [http://blockexplorer.com/tx/930a2114cdaa86e1fac46d15c74e81c09eee1d4150ff9d48e76cb0697d8e1d72 special transaction]. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

	Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).

	~~[[Category:Technical~~]]

Sgornick: Add definition of incident.

2012-04-22T03:39:08Z

Add definition of incident.

← Older revision		Revision as of 03:39, 22 April 2012
Line 1:		Line 1:
			Incidents in which a problem with the protocol was discovered or where the client mishandled the protocol, either of which were newsworthy or resolution required updated client software.

	== LSHIFT and RETURN bugs ==		== LSHIFT and RETURN bugs ==

Line 39:		Line 41:

	Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).		Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).

	[[Category:Technical]]		[[Category:Technical]]

Sgornick: Reorder chronologically.

2012-04-22T03:35:37Z

Reorder chronologically.

← Older revision		Revision as of 03:35, 22 April 2012
Line 1:		Line 1:
	== ~~Micropayment contamination~~ ==		== LSHIFT and RETURN bugs ==
	~~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~~.
			On July 28 2010 two bugs were discovered and demonstrated on the test network. The first caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT. The second exploited another bug in the transaction handling code and allowed an attacker to spend coins that they did not own. Neither were exploited on the main network, and both were fixed by Bitcoin version 0.3.5.

			After these bugs were discovered, many currently-unused [[script]] words were disabled for safety.

			== OP_CHECKSIG abuse ==

	~~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~~.		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).

	== Value overflow ==		== Value overflow ==
Line 23:		Line 28:
	Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9</pre>		Transaction hash: 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9</pre>

	== ~~OP_CHECKSIG abuse~~ ==		== Micropayment contamination ==

	~~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)~~.		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.

	~~== LSHIFT and RETURN bugs ==~~		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.

	~~On July 28 2010 two bugs were discovered and demonstrated on the test network~~. The ~~first caused bitcoin to crash on some machines when processing a transaction containing an OP_LSHIFT~~. ~~The second exploited another bug in the transaction handling code and allowed an attacker~~ to ~~spend coins that they did~~ not ~~own~~. ~~Neither were exploited on~~ the ~~main~~ network, and ~~both were fixed~~ by ~~Bitcoin version 0.3.5.~~

	~~After these bugs were discovered, many currently-unused [[script]] words were disabled for safety~~.

	== ASCII embedding into blockchain ==		== ASCII embedding into blockchain ==

	Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block which included a [http://blockexplorer.com/tx/930a2114cdaa86e1fac46d15c74e81c09eee1d4150ff9d48e76cb0697d8e1d72 special transaction]. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].		Occurred July 30, 2011. Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block which included a [http://blockexplorer.com/tx/930a2114cdaa86e1fac46d15c74e81c09eee1d4150ff9d48e76cb0697d8e1d72 special transaction]. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

	Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).		Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).
	[[Category:Technical]]		[[Category:Technical]]

Sgornick: Add the specific transaction that had the embedded ascii.

2012-04-06T22:56:07Z

Add the specific transaction that had the embedded ascii.

← Older revision		Revision as of 22:56, 6 April 2012
Line 35:		Line 35:
	== ASCII embedding into blockchain ==		== ASCII embedding into blockchain ==

	Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].		Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block which included a [http://blockexplorer.com/tx/930a2114cdaa86e1fac46d15c74e81c09eee1d4150ff9d48e76cb0697d8e1d72 special transaction]. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

	Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).		Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).
	[[Category:Technical]]		[[Category:Technical]]

BlueMatt: Later stuff was completely off-topic.

2012-01-23T22:33:32Z

Later stuff was completely off-topic.

← Older revision		Revision as of 22:33, 23 January 2012
Line 37:		Line 37:
	Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].		Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

	Block chain embedding should not really be seen as an attack~~, as~~ BitCoin is ultimately a channel by which arbitrary data is validated and retained over time. ~~Indeed~~, ~~the very first block~~ in ~~BitCoin~~ (the [[genesis block]]) contains a text message. More worrisome was the observation that arbitrary content can be inserted into a transaction after it has been released to miners, but before it has been included into a block. This was done via an arbitrary prefix on the ScriptSig. Furthermore, IP deanonymization was shown to be relatively straightforward for an attacker who can connect to a large number of nodes.		Though Block chain embedding should not really be seen as an attack (BitCoin is ultimately a channel by which arbitrary data is validated and retained over time), the ability of users to store arbitrary data in the blockchain is a potential avenue for abuse. That said, placing arbitrary data in a coinbase does not require additional space on user's drives (as the [[genesis block]] did).
	[[Category:Technical]]		[[Category:Technical]]

Justmoon: Fixed link to incident forum topic.

2011-09-06T16:05:21Z

Fixed link to incident forum topic.

← Older revision		Revision as of 16:05, 6 September 2011
Line 6:		Line 6:
	== Value overflow ==		== Value overflow ==

	On August 15 2010, it was [http://~~www.bitcoin~~.org~~/smf~~/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 "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.		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 "bad" block chain, the "good" block chain overtook it at a block height of 74691. The bad transaction no longer exists for people using the longest chain.

	The block and transaction:		The block and transaction:

Dakami at 21:16, 18 August 2011

2011-08-18T21:16:30Z

← Older revision		Revision as of 21:16, 18 August 2011
Line 35:		Line 35:
	== ASCII embedding into blockchain ==		== ASCII embedding into blockchain ==

	Security researchers Dan ~~Kaminski~~ and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011 ~~-- days~~ prior to ~~Kaminski~~'s presentation at the ~~BlackHat hacker~~ conference ~~in which Kaminski will discuss "BitCoin~~: ~~Network Manipulation for Fun And (Literal) Profit"~~.		Security researchers Dan Kaminsky and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011, prior to Kaminsky's presentation at the Black Hat Briefings conference entitled [http://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 Black Ops Of TCP/IP 2011].

	~~This "attack" is harmless and has been known forever~~. ~~It was used to insert a message into the [[genesis block]~~].

			Block chain embedding should not really be seen as an attack, as BitCoin is ultimately a channel by which arbitrary data is validated and retained over time. Indeed, the very first block in BitCoin (the [[genesis block]]) contains a text message. More worrisome was the observation that arbitrary content can be inserted into a transaction after it has been released to miners, but before it has been included into a block. This was done via an arbitrary prefix on the ScriptSig. Furthermore, IP deanonymization was shown to be relatively straightforward for an attacker who can connect to a large number of nodes.
	[[Category:Technical]]		[[Category:Technical]]

Theymos: /* ASCII embedding into blockchain */

2011-08-02T06:32:44Z

ASCII embedding into blockchain

← Older revision		Revision as of 06:32, 2 August 2011
Line 36:		Line 36:

	Security researchers Dan Kaminski and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011 -- days prior to Kaminski's presentation at the BlackHat hacker conference in which Kaminski will discuss "BitCoin: Network Manipulation for Fun And (Literal) Profit".		Security researchers Dan Kaminski and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011 -- days prior to Kaminski's presentation at the BlackHat hacker conference in which Kaminski will discuss "BitCoin: Network Manipulation for Fun And (Literal) Profit".

			This "attack" is harmless and has been known forever. It was used to insert a message into the [[genesis block]].

	[[Category:Technical]]		[[Category:Technical]]

Sgornick: Add ASCII embedding into blockchain incident.

2011-08-01T07:22:43Z

Add ASCII embedding into blockchain incident.

← Older revision		Revision as of 07:22, 1 August 2011
Line 32:		Line 32:

	After these bugs were discovered, many currently-unused [[script]] words were disabled for safety.		After these bugs were discovered, many currently-unused [[script]] words were disabled for safety.

			== ASCII embedding into blockchain ==

			Security researchers Dan Kaminski and Travis Goodspeed successfully embedded [http://pastebin.com/raw.php?i=BUB3dygQ extraneous text] into the blockchain from a mined block. This was disclosed on July 31, 2011 -- days prior to Kaminski's presentation at the BlackHat hacker conference in which Kaminski will discuss "BitCoin: Network Manipulation for Fun And (Literal) Profit".

	[[Category:Technical]]		[[Category:Technical]]

Gavinandresen: Changed tense of "A 0.01 fee is required" (fees changed in version 0.3.22/0.3.23)

2011-06-10T02:04:37Z

Changed tense of "A 0.01 fee is required" (fees changed in version 0.3.22/0.3.23)

← Older revision		Revision as of 02:04, 10 June 2011
Line 1:		Line 1:
	== Micropayment contamination ==		== Micropayment contamination ==
	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 is 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.		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.

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