Transaction expiration: Difference between revisions
No edit summary |
No edit summary |
||
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]] |
Latest revision as of 03:36, 25 May 2017
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 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.
- 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 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 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.