Weaknesses - Revision history

Murch: /* Denial of Service (DoS) attacks */ Fix typo "UXTO" ⇒ "UTXO"

2023-10-30T13:44:12Z

Denial of Service (DoS) attacks: Fix typo "UXTO" ⇒ "UTXO"

← Older revision		Revision as of 13:44, 30 October 2023
Line 70:		Line 70:

	# Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).		# Transactions greater than 100 Kbytes are considered non-standard (protects from variations of the https://bitcointalk.org/index.php?topic=140078.0 attack).
	# Only the ~~UXTO~~ (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.		# Only the UTXO (Unspent Transaction Output Set) is stored in memory, the remaining data is stored on disk.
	# 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)		# 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)

AllEd01: /* Denial of Service (DoS) attacks */ added extra info and reference, corrected spelling

2022-06-30T13:44:49Z

Denial of Service (DoS) attacks: added extra info and reference, corrected spelling

AllEd01: /* Wallet Vulnerable To Theft */ spell and gramar check

2022-06-30T12:42:48Z

Wallet Vulnerable To Theft: spell and gramar check

← Older revision		Revision as of 12:42, 30 June 2022
Line 2:		Line 2:
	=== Wallet Vulnerable To Theft ===		=== Wallet Vulnerable To Theft ===

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

	==== New wallets vulnerable with old passwords via backups ====		==== New wallets vulnerable with old passwords via backups ====
Line 8:		Line 8:
	An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.		An old copy of a wallet with its old password is often easily retrievable via an existing backup facility (particularly Apple Time-Machine): draining that old wallet, with its old password, drains the current wallet with the current password -- this is contrary to most non-technical users expectation of what 'change the password on your wallet' should mean following password compromise.

	An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause) ~~the~~ creation of a new wallet with new addresses, and the sending of existing sums to them. Backed-up copies of the original wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and ~~- intially~~ at least - the new wallet is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.		An initial solution is to mandate (either in code or as expressed policy) that changing a wallet's password causes (or asks the user to cause). The creation of a new wallet with new addresses and the sending of existing sums to them. Backed-up copies of the original wallet with the original password would then be empty, should they be compromised. On the downside, the password-changing process would potentially take much longer, cost a transaction fee or more, and initially at least, the new wallet is no longer backed up. On the upside, non-technical users won't find their wallets drained from security compromises they believed they had closed, nor be required to locate existing backups of a wallet in order to destroy them.

	=== Tracing a coin's history ===		=== Tracing a coin's history ===

Furunodo: /* Illegal content in the block chain */

2020-06-27T12:53:53Z

Illegal content in the block chain

← Older revision		Revision as of 12:53, 27 June 2020
Line 81:		Line 81:

	=== Illegal content in the block chain ===		=== Illegal content in the block chain ===
	It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data are non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 Various ideas have been proposed] to further limit data storage in the UTXO set (but are not currently being seriously considered for deployment).		It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data are non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 Various ideas have been proposed] to further limit data storage in the [[UTXO\|UTXO set]] (but are not currently being seriously considered for deployment).

	=== Security Vulnerabilities and bugs ===		=== Security Vulnerabilities and bugs ===

CarbonChris: I felt the wording in this section did not carry the full weight of the threat and power possessed by an attacker with 'majority' hash power. Specifically and most importantly, the attacker can affect an entire coin history with a double spend.

2018-07-24T08:45:13Z

I felt the wording in this section did not carry the full weight of the threat and power possessed by an attacker with 'majority' hash power. Specifically and most importantly, the attacker can affect an entire coin history with a double spend.

← Older revision		Revision as of 08:45, 24 July 2018
Line 118:		Line 118:
	=== Attacker has a lot of computing power ===		=== Attacker has a lot of computing power ===
	An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:		An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
	* Reverse transactions that he sends while he's in control. This has the potential to [[Double-spending#51.25_attack\|double-spend transactions]] that previously had already been seen in the block chain.		* 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, affecting all coins that share a history with the reversed transaction
			* Reverse confirmations for any transaction that had previously been seen in the block chain while he’s in control.
	* Prevent some or all transactions from gaining any confirmations		* Prevent some or all transactions from gaining any confirmations
	* Prevent some or all other miners from mining any valid blocks		* Prevent some or all other miners from mining any valid blocks
	The attacker ''can't'':		The attacker ''can't'':
	* Reverse other people's transactions without their cooperation		* Reverse other people's transactions without their cooperation (unless their coin history has been affected by a double-spend)
	* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)		* Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
	* Change the number of coins generated per block		* Change the number of coins generated per block

Randolf: /* Illegal content in the block chain */ Fixed a spelling error, improved a link's title, and moved one portion into parenthesis

2018-02-04T14:59:02Z

Illegal content in the block chain: Fixed a spelling error, improved a link's title, and moved one portion into parenthesis

← Older revision		Revision as of 14:59, 4 February 2018
Line 81:		Line 81:

	=== Illegal content in the block chain ===		=== Illegal content in the block chain ===
	It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data re non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. ~~Various ideas have~~ [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 been proposed] to further limit ~~datastorage~~ in the UTXO set but are not currently being seriously considered for deployment.		It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and full Bitcoin nodes must normally have a copy of all unspent transactions, this could cause legal problems. However, Local node policy generally doesn't permit arbitrary data (transactions attempting to embed data are non-standard), but steganographic embedding can still be used though this generally limits storage to small amounts. [http://sourceforge.net/mailarchive/message.php?msg_id=30705609 Various ideas have been proposed] to further limit data storage in the UTXO set (but are not currently being seriously considered for deployment).

	=== Security Vulnerabilities and bugs ===		=== Security Vulnerabilities and bugs ===

Randolf: /* Tracing a coin's history */ Improved link to "Anonymity" article

2018-02-04T14:55:02Z

Tracing a coin's history: Improved link to "Anonymity" article

← Older revision		Revision as of 14:55, 4 February 2018
Line 11:		Line 11:

	=== Tracing a coin's history ===		=== Tracing a coin's history ===
	Tracing a coin's history can be used to connect identities to addresses. [[Anonymity~~\|More info~~]].		Tracing a coin's history can be used to connect identities to addresses (the [[Anonymity]] article elaborates on this concern in greater detail).

	=== Sybil attack ===		=== Sybil attack ===

Randolf: /* Sybil attack */ More improvements to the writing style

2018-02-04T14:51:00Z

Sybil attack: More improvements to the writing style

← Older revision		Revision as of 14:51, 4 February 2018
Line 14:		Line 14:

	=== Sybil attack ===		=== Sybil attack ===
	An attacker ~~can attempt~~ to fill the network with clients ~~controlled by him~~, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.		If an attacker attempts to fill the network with clients that they control, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.

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

	* ~~The~~ attacker can refuse to relay blocks and transactions from everyone, disconnecting you from the network.		* the attacker can refuse to relay blocks and transactions from everyone, effectively disconnecting you from the network
	* ~~The~~ attacker can relay only blocks that ~~he creates~~, putting you on a separate network~~. You're~~ then open to [[double-spending]] attacks.		* the attacker can relay only blocks that they create, effectively putting you on a separate network and then also leaving you open to [[double-spending]] attacks
	* If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending ~~attack.~~		* if you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute [[double-spending]] attacks
	* ~~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.		* low-latency encryption/anonymization of Bitcoin's transmissions (with Tor, JAP, etc.) can be defeated relatively easily with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP

	Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case, where you're probably already unable to accept incoming connections.		Bitcoin makes these attacks more difficult by only making an outbound connection to one IP address per /16 (x.y.0.0). Incoming connections are unlimited and unregulated, but this is generally only a problem in the anonymity case where you're probably already unable to accept incoming connections.

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

	=== Packet sniffing ===		=== Packet sniffing ===

Randolf: /* Sybil attack */ Added a comma so the first paragraph makes sense

2018-02-04T07:56:31Z

Sybil attack: Added a comma so the first paragraph makes sense

← Older revision		Revision as of 07:56, 4 February 2018
Line 14:		Line 14:

	=== Sybil attack ===		=== Sybil attack ===
	An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything completely isolating a node from the honest network can be helpful in the execution of other attacks.		An attacker can attempt to fill the network with clients controlled by him, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.

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

Belcher: /* Attacker has a lot of computing power */ added link to majority attack page

2017-07-04T14:36:32Z

Attacker has a lot of computing power: added link to majority attack page

← Older revision		Revision as of 14:36, 4 July 2017
Line 141:		Line 141:

	The appropriate response to any long-term attack by miners is a [[hardfork]] to change the proof-of-work function. This fires all existing miners, and allows totally new ones to replace them.		The appropriate response to any long-term attack by miners is a [[hardfork]] to change the proof-of-work function. This fires all existing miners, and allows totally new ones to replace them.

			See also: [[Majority_attack]]

	=== Spamming transactions ===		=== Spamming transactions ===

← Older revision		Revision as of 13:44, 30 June 2022
Line 31:		Line 31:

	=== Denial of Service (DoS) attacks ===		=== Denial of Service (DoS) attacks ===
	~~Sending lots~~ of data to a ~~node may make it so busy it cannot process~~ normal Bitcoin transactions. Bitcoin has some denial-of-service prevention built-in, ~~but is~~ likely still vulnerable to more sophisticated denial-of-service attacks.		In most cases, a denial of service (DoS) happens when a node is overloaded by too much data being sent. A DoS attack is caused deliberately by external parties.<ref>https://www.ionos.com/digitalguide/server/know-how/dos-and-ddos-attack-patterns-at-a-glance/</ref> This means that normal Bitcoin transactions cannot be made, although Bitcoin has some denial-of-service prevention built-in, it's likely still vulnerable to more sophisticated denial-of-service attacks.

	These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:		These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:
Line 37:		Line 37:
	# Does not forward orphan transactions/blocks		# Does not forward orphan transactions/blocks
	# Does not forward double-spend transactions		# Does not forward double-spend transactions
	# Does not forward the same block, transaction or alert twice to the same peer.		# Does not forward the same block, transaction, or alert twice to the same peer.
	# Continuous rate-limit of free transactions to mitigate 'penny-flooding'		# Continuous rate-limit of free transactions to mitigate 'penny-flooding'
	# Keeps a DoS score of each connected peer and disconnects from a peer that ~~send~~ messages that fail to comply with the rules.		# Keeps a DoS score of each connected peer and disconnects from a peer that sends messages that fail to comply with the rules.
	# Bans IP addresses that misbehave for a time lapse (24 hours default)		# Bans IP addresses that misbehave for a time-lapse (24 hours default)
	# Limits the number of stored orphan transactions (10000 by default)		# Limits the number of stored orphan transactions (10000 by default)
	# 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)		# 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)
Line 47:		Line 47:
	# Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.		# Penalizes peers that send lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
	# In orphan/signature caches, when removing an item, evicts a random entry.		# In orphan/signature caches, when removing an item, evicts a random entry.
	# Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker ~~that result~~ in exponential complexity.		# Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker resulting in an exponential complexity.
	# Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.		# Ignores big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
	# In RPC: Only sends a HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.		# In RPC: Only sends an HTTP 403 response if it's not using SSL to prevent a DoS during the SSL handshake.
	# In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.		# In RPC: Sleeps some time if authorization fails to deter brute-forcing short passwords.
	# In GUI: Limits URI length to prevent a DoS against the QR-Code dialog		# In GUI: Limits URI length to prevent a DoS against the QR-Code dialog
Line 61:		Line 61:
	# Restricts the maximum number of signature checks a transaction input may request		# Restricts the maximum number of signature checks a transaction input may request
	# Limits the size of each script (up to 10000 bytes)		# Limits the size of each script (up to 10000 bytes)
	# Limits the size of each value pushed while evaluating a a script (up to 520 bytes)		# Limits the size of each value pushed while evaluating a script (up to 520 bytes)
	# 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.		# 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.
	# Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)		# Limits the number of key arguments OP_CHECKMULTISIG can use (up to 20 keys)
	# Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)		# Limits the number of the stack elements that can be stored simultaneously (up to 1000 elements, in standard and alt stacks together)