Transaction expiration - Revision history

Theymos at 03:36, 25 May 2017

2017-05-25T03:36:13Z

← Older revision		Revision as of 03:36, 25 May 2017
Line 8:		Line 8:
	# The recipient uses [[CPFP\|child-pays-for-parent (CPFP)]] to get the first transaction to ''also'' confirm. You have now paid twice, losing BTC, even though the first transaction "expired".		# The recipient uses [[CPFP\|child-pays-for-parent (CPFP)]] to get the first transaction to ''also'' confirm. You have now paid twice, losing BTC, even though the first transaction "expired".

	It ''is'' possible to create two transactions that are mutually exclusive. For example, the proper way of increasing the fee in the above example would be to send another transaction that ''uses exactly the same [[Coin analogy\|coins]]'' as the first transaction. Since a single coin can't be spent more than once, only one of the transactions will ever confirm. Actual losses due to the insane expiration behavior of certain wallets are rare because wallets often ''accidentally'' use the same coins when recreating an "expired" transaction, but it is very reckless to rely on this.		It ''is'' possible to create two transactions that are mutually exclusive. For example, the proper way of [[Fee bumping\|increasing the fee]] in the above example would be to send another transaction that ''uses exactly the same [[Coin analogy\|coins]]'' as the first transaction. Since a single coin can't be spent more than once, only one of the transactions will ever confirm. Actual losses due to the insane expiration behavior of certain wallets are rare because wallets often ''accidentally'' use the same coins when recreating an "expired" transaction, but it is very reckless to rely on this.

	This myth may have been started by [[Bitcoin Core]]'s default behavior of removing transactions from its [[memory pool]] after 72 hours (later changed to 2 weeks). Due to this behavior, it became likely in most cases that a transaction would never confirm after it went 72 hours unconfirmed. However, just because ''most'' nodes will forget about a transaction doesn't mean that everyone must or will do so. You have to plan for the worst case, not the typical case.		This myth may have been started by [[Bitcoin Core]]'s default behavior of removing transactions from its [[memory pool]] after 72 hours (later changed to 2 weeks). Due to this behavior, it became likely in most cases that a transaction would never confirm after it went 72 hours unconfirmed. However, just because ''most'' nodes will forget about a transaction doesn't mean that everyone must or will do so. You have to plan for the worst case, not the typical case.

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

Theymos at 21:02, 14 May 2017

2017-05-14T21:02:24Z

← Older revision		Revision as of 21:02, 14 May 2017
Line 1:		Line 1:
	Transaction expiration is a common ''myth/misconception''. Once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, get stuck at 0 confirmations for some ''years'', and then all of a sudden confirm.		Transaction expiration is a common ''myth/misconception''. Once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, get stuck at 0 confirmations for some ''years'', and then all of a sudden confirm.

	Several wallets have the behavior of deleting outgoing transactions after a few days of being unconfirmed. This is insane, and could lead to losses. Consider the following example		Several wallets have the behavior of deleting outgoing transactions from their transaction list after a few days of being unconfirmed. This is insane, and could lead to losses. Consider the following example

	# You send a transaction. It gets stuck due to having a too-low fee.		# You send a transaction. It gets stuck due to having a too-low fee.

Theymos: Created page with "Transaction expiration is a common ''myth/misconception''. Once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, ge..."

2017-05-14T21:00:52Z

Created page with "Transaction expiration is a common ''myth/misconception''. Once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, ge..."

New page

Transaction expiration is a common ''myth/misconception''. Once a Bitcoin transaction is created, it never automatically expires. In theory, a transaction could be created, get stuck at 0 confirmations for some ''years'', and then all of a sudden confirm.

Several wallets have the behavior of deleting outgoing transactions after a few days of being unconfirmed. This is insane, and could lead to losses. Consider the following example

# You send a transaction. It gets stuck due to having a too-low fee.
# Your wallet deletes the transaction after a number of days.
# You still want to send the transaction, so you create a new transaction with the same value but a higher fee. This confirms.
# The recipient uses [[CPFP|child-pays-for-parent (CPFP)]] to get the first transaction to ''also'' confirm. You have now paid twice, losing BTC, even though the first transaction "expired".

It ''is'' possible to create two transactions that are mutually exclusive. For example, the proper way of increasing the fee in the above example would be to send another transaction that ''uses exactly the same [[Coin analogy|coins]]'' as the first transaction. Since a single coin can't be spent more than once, only one of the transactions will ever confirm. Actual losses due to the insane expiration behavior of certain wallets are rare because wallets often ''accidentally'' use the same coins when recreating an "expired" transaction, but it is very reckless to rely on this.

This myth may have been started by [[Bitcoin Core]]'s default behavior of removing transactions from its [[memory pool]] after 72 hours (later changed to 2 weeks). Due to this behavior, it became likely in most cases that a transaction would never confirm after it went 72 hours unconfirmed. However, just because ''most'' nodes will forget about a transaction doesn't mean that everyone must or will do so. You have to plan for the worst case, not the typical case.

[[Category:Technical]]