Timeline for Can a low fee unconfirmed transaction prevent confirmations of following transactions?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2017 at 17:55 | comment | added | Nate Eldredge | @AhiaCohen: Yes it can, and wallets often do this. This is based on the common case that #1 will confirm pretty soon, and the user may not want to wait before creating more transactions. If fees are sufficient and block space is not in short supply (which was the case when most current wallet software was designed) then it is nice to be able to queue up multiple transactions, and they could all get confirmed together in the very next block. | |
| Dec 8, 2017 at 16:25 | vote | accept | Ahia Cohen | ||
| Dec 8, 2017 at 16:25 | comment | added | Ahia Cohen | Thanks, that clarifies it a bit. Just one final bit: Can the wallet choose to take as input for #2, the output of #1 even though it's not confirmed? I assumed it can only take as outputs things that are already registered in the blockchain, but if not, then I should probably be angry at my wallet for causing this mess. | |
| Dec 8, 2017 at 14:47 | comment | added | Nate Eldredge | @AhiaCohen: I see. Yes, that is the situation I described in my response to (1); in that case, your #2 is what I called #1a. It has all the usual issues of a double spend. Wallet software will normally not do this by default; they will prefer to spend the "change" output from #1, since they assume that you actually want #1 to confirm if possible. | |
| Dec 8, 2017 at 7:29 | comment | added | Ahia Cohen | About (2), but since #1 is unconfirmed yet, it's not in the blockchain. And as input, #2 can take the original input into the wallet of the 4 BTC, no (since #1 is unconfirmed, there's still an UTXO of 4 BTC in address A). | |
| Dec 8, 2017 at 7:06 | comment | added | Nate Eldredge | @AhiaCohen: (2) You cannot confirm #2 before (or without) #1, that is what I am saying. It's a protocol rule that a transaction in a block may only reference inputs which already exist as outputs of previous transactions. Any block that contains #2, if #1 is not already in a previous block in the chain (or earlier in the same block), is an invalid block and will be rejected by the network. Miners do and must check this. | |
| Dec 8, 2017 at 7:04 | comment | added | Nate Eldredge | @AhiaCohen (1) It's not permanently "locked". Even if #1 is never confirmed, you may still create a different transaction #1a which spends your original 4 BTC input, sending it either to address B or anywhere else you want. This is a double-spend, and other nodes on the network may not like you very much if you send it while they still have #1 in their mempool (Bitcoin Core will disconnect from you and ban your IP for a while, I think), but it's not forbidden by the protocol, and #1a could eventually get confirmed in place of #1. | |
| Dec 8, 2017 at 6:38 | comment | added | Ahia Cohen | Two followup clarifications: (1) Does that mean you can effectively lock your use of a wallet, since you had just one silly transaction with low fees, and all your bitcoins arrived using a single input into a single address? (2) Why would it matter, if in my example the 2 transactions are floating in the mempool, and you can confirm either one of them first without even knowing about the former. Do miners check every transaction they confirm against every other transaction in the pool as well? | |
| Dec 8, 2017 at 2:39 | history | answered | Nate Eldredge | CC BY-SA 3.0 |