Irreversible Transactions - Revision history

Tris T7: /* How many confirmations are required */ edited ref

2022-04-08T16:39:02Z

How many confirmations are required: edited ref

← Older revision		Revision as of 16:39, 8 April 2022
Line 47:		Line 47:
	The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. An online calculator can be found here: https://people.xiph.org/~greg/attack_success.html		The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. An online calculator can be found here: https://people.xiph.org/~greg/attack_success.html

	For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>. Because of the opportunity cost of this attack, it is only game-theory possible if the bitcoin amount traded is comparable to the block reward (but note that an attacking miner can attempt a brute force attack against several counterparties at once).		For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%.<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref> Because of the opportunity cost of this attack, it is only game-theory possible if the bitcoin amount traded is comparable to the block reward (but note that an attacking miner can attempt a brute force attack against several counterparties at once).

	If the bitcoin amount being transacted is so large that it is comparable to the block reward, then merchants should wait 100 confirmations for their incoming transactions to be irreversible.		If the bitcoin amount being transacted is so large that it is comparable to the block reward, then merchants should wait 100 confirmations for their incoming transactions to be irreversible.

Tris T7: /* Finney attack */ edited ref

2022-04-08T16:38:06Z

Finney attack: edited ref

← Older revision		Revision as of 16:38, 8 April 2022
Line 19:		Line 19:
	===Finney attack===		===Finney attack===

	Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but some miner hash power is required and a specific sequence of events must occur. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.		Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined.<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref> The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but some miner hash power is required and a specific sequence of events must occur. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.

	A Finney attack works as follows: Suppose the attacker is generating blocks occasionally. in each block he generates, he includes a transfer from address A to address B, both of which he controls. To cheat you, when he generates a block, he doesn't broadcast it. Instead, he opens your store web page and makes a payment to your address C with his address A. You may wait a few seconds for double-spends, not hear anything, and then transfer the goods. He broadcasts his block now, and his transaction will take precedence over yours.		A Finney attack works as follows: Suppose the attacker is generating blocks occasionally. in each block he generates, he includes a transfer from address A to address B, both of which he controls. To cheat you, when he generates a block, he doesn't broadcast it. Instead, he opens your store web page and makes a payment to your address C with his address A. You may wait a few seconds for double-spends, not hear anything, and then transfer the goods. He broadcasts his block now, and his transaction will take precedence over yours.

Tris T7: /* Race attack */ edit ref

2022-04-08T16:36:16Z

Race attack: edit ref

← Older revision		Revision as of 16:36, 8 April 2022
Line 15:		Line 15:
	Merchants can take precautions (e.g., disable incoming connections, only connect to well connected nodes) to lessen the risk of a race attack but the risk cannot be eliminated. Therefore, the cost/benefit of the risk needs to be considered when accepting payment on 0/unconfirmed when there is no recourse against the attacker.		Merchants can take precautions (e.g., disable incoming connections, only connect to well connected nodes) to lessen the risk of a race attack but the risk cannot be eliminated. Therefore, the cost/benefit of the risk needs to be considered when accepting payment on 0/unconfirmed when there is no recourse against the attacker.

	The [[research]] paper [http://eprint.iacr.org/2012/248.pdf Two Bitcoins at the Price of One] finds that the protocol allows a high degree of success by an attacker in performing race attacks. The method studied in the research paper depends on access to the merchant's Bitcoin node which is why that even prior to this paper, recommendations for merchants include disabling incoming connections and to choose specific outgoing connections<ref>[http://bitcointalk.org/index.php?topic=79090.msg881283#msg881283 BitcoinTalk Thread - Two Bitcoins at the Price of One]</ref>.		The [[research]] paper [http://eprint.iacr.org/2012/248.pdf Two Bitcoins at the Price of One] finds that the protocol allows a high degree of success by an attacker in performing race attacks. The method studied in the research paper depends on access to the merchant's Bitcoin node which is why that even prior to this paper, recommendations for merchants include disabling incoming connections and to choose specific outgoing connections.<ref>[http://bitcointalk.org/index.php?topic=79090.msg881283#msg881283 BitcoinTalk Thread - Two Bitcoins at the Price of One]</ref>

	===Finney attack===		===Finney attack===

Belcher: /* Bribing miners to reorg a confirmed transaction */ replaced deleted post link with archive.is

2021-03-31T19:07:56Z

Bribing miners to reorg a confirmed transaction: replaced deleted post link with archive.is

← Older revision		Revision as of 19:07, 31 March 2021
Line 57:		Line 57:
	Examples:		Examples:

	* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://~~old~~.~~reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj~~/		* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://archive.is/S2fBH

	* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144		* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144

Belcher: Add link to DCI's pool detective

2021-01-06T00:14:32Z

Add link to DCI's pool detective

← Older revision		Revision as of 00:14, 6 January 2021
Line 80:		Line 80:
	* [https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 Thorough discussion of zero-confirm on-chain transactions in bitcoin] by Bram Cohen		* [https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 Thorough discussion of zero-confirm on-chain transactions in bitcoin] by Bram Cohen
	* [https://bitcoin.stackexchange.com/questions/87652/51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t/87655#87655 stackexchange discussion on exchanges bribing miners to reverse transactions]		* [https://bitcoin.stackexchange.com/questions/87652/51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t/87655#87655 stackexchange discussion on exchanges bribing miners to reverse transactions]
			* [https://pooldetective.org/ MIT DCI’s pool detective app monitors various mining pools for odd behaviour like censorship, selfish mining or reorg attempts]


	[[de:Doppelausgaben]]		[[de:Doppelausgaben]]

Belcher: /* Bribing miners to reorg a confirmed transaction */ Update reddit link to use old.

2020-01-24T20:47:44Z

Bribing miners to reorg a confirmed transaction: Update reddit link to use old.

← Older revision		Revision as of 20:47, 24 January 2020
Line 57:		Line 57:
	Examples:		Examples:

	* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://~~www~~.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj/		* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://old.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj/

	* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144		* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144

Belcher: Add section on how many confirmations are needed, and about bribing miners to reorg

2020-01-24T16:05:29Z

Add section on how many confirmations are needed, and about bribing miners to reorg

← Older revision		Revision as of 16:05, 24 January 2020
Line 31:		Line 31:
	See on [http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 BitcoinTalk] or further [http://www.reddit.com/r/Bitcoin/comments/2e7bfa/vector76_double_spend_attack/cjwya6x example of an attack scenario].		See on [http://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 BitcoinTalk] or further [http://www.reddit.com/r/Bitcoin/comments/2e7bfa/vector76_double_spend_attack/cjwya6x example of an attack scenario].

	===~~Alternative history~~ attack===		=== Blockchain reorganization attack===

	This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate and risk of significant expense in wasted electricity to the attacking miner.		Also called alternative history attack. This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate and risk of significant expense in wasted electricity to the attacking miner.

	The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this then the attack fails, the attacker has wasted a significant amount of electricity and the payment to the merchant will ~~go through~~.		The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. After waiting for ''n'' confirmations, the merchant sends the product. If the attacker happened to find more than ''n'' blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this then the attack fails, the attacker has wasted a significant amount of electricity and the payment to the merchant will not be reversed.

	The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. An online calculator can be found [https://people.xiph.org/~greg/attack_success.html ~~here]~~		===[[Majority attack]]===

			Also referred to as a 51% attack or >50% attack. If the attacker controls more than half of the network hashrate, the previously-mentioned Alternative history attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.

			No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could potentially make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. Bitcoin's security model relies on no single coalition of miners controlling more than half the mining power. A miner with more than 50% hash power is incentived to reduce their mining power and reframe from attacking in order for their mining equipment and bitcoin income to retain it's value.

			== How many confirmations are required ==

			The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. An online calculator can be found here: https://people.xiph.org/~greg/attack_success.html

	For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>. Because of the opportunity cost of this attack, it is only game-theory possible if the bitcoin amount traded is comparable to the block reward (but note that an attacking miner can attempt a brute force attack against several counterparties at once).		For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%<ref>[https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]</ref>. Because of the opportunity cost of this attack, it is only game-theory possible if the bitcoin amount traded is comparable to the block reward (but note that an attacking miner can attempt a brute force attack against several counterparties at once).

	===[[~~Majority attack~~]]===		If the bitcoin amount being transacted is so large that it is comparable to the block reward, then merchants should wait 100 confirmations for their incoming transactions to be irreversible.

			=== Bribing miners to reorg a confirmed [[transaction]] ===

			In the past after large bitcoin thefts, it has been suggested that the theft victim attempts to bribe miners into reversing the confirmed transaction. This does not work because the thief can easily outbid with their own bribe. The thief gets a head-start as the transaction would already have confirmations. Every block that gets mined adds a block reward amount of bitcoins more that the attacker could keep while still paying more than the victim, as is every percentage of hashpower that doesn't go along with it. Such a reorg attempt, if successful, would also cause massive disruption in the bitcoin network and open the reorganizing miners and victim to litigation.

			Examples:

	~~Also referred to as~~ a ~~51% attack or >50% attack~~. ~~If the attacker controls more than half of the network hashrate, the previously-mentioned Alternative history attack has~~ a ~~probability of 100%~~ to ~~succeed~~. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.		* In August 2016 the Bitfinex exchange suffered a hack of 120000 bitcoins. Here is a reddit discussion involving bitcoin experts about bribing miners to reorg and why that's a bad idea: https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj/

	No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could potentially make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. Bitcoin's security model relies on no single coalition of miners controlling more than half the ~~mining power. A miner with more than 50% hash power is incentived to reduce their mining power and reframe from attacking in order~~ for ~~their mining equipment~~ and ~~bitcoin income to retain it's value~~.		* In May 2019 the Binance exchange was hacked for 7000 bitcoins and a similar suggestion was made: https://twitter.com/JeremyRubin/status/1125919526485254144

	==Successful Double-Spends in Practice==		==Successful Double-Spends in Practice==

Belcher: /* See Also */ Add link to stackexchange discussion on merchants bribing miners to reverse txes

2019-05-12T16:49:58Z

See Also: Add link to stackexchange discussion on merchants bribing miners to reverse txes

← Older revision		Revision as of 16:49, 12 May 2019
Line 65:		Line 65:
	* [http://codinginmysleep.com/bitcoin-attacks-in-plain-english Bitcoin Attacks in Plain English] by David Perry		* [http://codinginmysleep.com/bitcoin-attacks-in-plain-english Bitcoin Attacks in Plain English] by David Perry
	* [https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 Thorough discussion of zero-confirm on-chain transactions in bitcoin] by Bram Cohen		* [https://medium.com/@bramcohen/the-inevitable-demise-of-unconfirmed-bitcoin-transactions-8b5f66a44a35 Thorough discussion of zero-confirm on-chain transactions in bitcoin] by Bram Cohen
			* [https://bitcoin.stackexchange.com/questions/87652/51-attack-apparently-very-easy-refering-to-czs-rollback-btc-chain-how-t/87655#87655 stackexchange discussion on exchanges bribing miners to reverse transactions]

	[[de:Doppelausgaben]]		[[de:Doppelausgaben]]

Belcher: /* Finney attack */ added / copypasted writeup of how a finney attack works

2018-03-15T21:57:22Z

Finney attack: added / copypasted writeup of how a finney attack works

← Older revision		Revision as of 21:57, 15 March 2018
Line 19:		Line 19:
	===Finney attack===		===Finney attack===

	Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but ~~the participation of a~~ miner is required and a specific sequence of events must occur~~. Thus the attack is not trivial to perform and only makes sense for the attacker when the gains from the attack are significant~~. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.		Another attack the trader or merchant is exposed to when accepting payment on 0/unconfirmed. The Finney attack is a fraudulent double-spend that requires the participation of a miner once a block has been mined<ref>[http://www.bitcointalk.org/index.php?topic=3441.msg48384#msg48384 Best practice for fast transaction acceptance - how high is the risk?]</ref>. The risk of a Finney attack cannot be eliminated regardless of the precautions taken by the merchant, but some miner hash power is required and a specific sequence of events must occur. Just like with the race attack, a trader or merchant should consider the cost / benefit when accepting payment on just one confirmation when there is no recourse against the attacker.

			A Finney attack works as follows: Suppose the attacker is generating blocks occasionally. in each block he generates, he includes a transfer from address A to address B, both of which he controls. To cheat you, when he generates a block, he doesn't broadcast it. Instead, he opens your store web page and makes a payment to your address C with his address A. You may wait a few seconds for double-spends, not hear anything, and then transfer the goods. He broadcasts his block now, and his transaction will take precedence over yours.

	===Vector76 attack===		===Vector76 attack===

Belcher: /* Majority attack */ made wording clearer

2018-02-18T01:20:08Z

Majority attack: made wording clearer

← Older revision		Revision as of 01:20, 18 February 2018
Line 41:		Line 41:
	===[[Majority attack]]===		===[[Majority attack]]===

	Also referred to as a 51% attack or >50% attack. If the attacker controls more than half of the network hashrate, the ~~previous~~ attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.		Also referred to as a 51% attack or >50% attack. If the attacker controls more than half of the network hashrate, the previously-mentioned Alternative history attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.

	No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could potentially make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. Bitcoin's security model relies on no single coalition of miners controlling more than half the mining power. A miner with more than 50% hash power is incentived to reduce their mining power and reframe from attacking in order for their mining equipment and bitcoin income to retain it's value.		No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could potentially make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in. Bitcoin's security model relies on no single coalition of miners controlling more than half the mining power. A miner with more than 50% hash power is incentived to reduce their mining power and reframe from attacking in order for their mining equipment and bitcoin income to retain it's value.