<p>Yes, if the second transaction spends the output of the first one, then #2 cannot be confirmed until after #1 is confirmed.  (Though they can be confirmed in a single block, as long as #1 appears before #2 in that block, in which case the confirmations are effectively simultaneous.)</p>

<p>Most miners will consider transactions on a "child pays for parent" basis, so that a low fee for #1 could be compensated by a high fee in #2.  The two transactions would be considered as a single "lump" with their combined fee, and a miner would confirm them if the combined lump pays a higher fee than the next most lucrative transaction (or lump) that could fill that space.</p>

CC BY-SA 3.0
2017-12-08T06:38:46.927Z
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?
Ahia Cohen
CC BY-SA 3.0
2017-12-08T07:04:57.493Z
@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.
Nate Eldredge
CC BY-SA 3.0
2017-12-08T07:06:35.410Z
@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.
Nate Eldredge
CC BY-SA 3.0
2017-12-08T07:29:55.347Z
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).
Ahia Cohen
CC BY-SA 3.0
2017-12-08T14:47:41.107Z
@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.
Nate Eldredge
CC BY-SA 3.0
2017-12-08T16:25:49.893Z
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.
Ahia Cohen
CC BY-SA 3.0
2017-12-08T17:55:20.713Z
@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.
Nate Eldredge
CC BY-SA 3.0
2017-12-08T02:39:05.700Z
2017-12-08T02:39:05.700Z
Nate Eldredge
<p>To be more precise, consider the following situation:</p>

<ol>
<li>Address A gets an input of 4 BTC.</li>
<li>You try to make a transaction from A to B with 1 BTC and a very low fee, which means its unconfirmed for a long while. The transaction's output are B and A (to account for the change of ~3 BTC after fees)</li>
<li>Before waiting for the previous transaction to be confirmed, you send again from A to B, this time you send 2 BTC with a higher fee, hoping it'll be confirmed fast.</li>
</ol>

<p>My question is, since the output of the first transaction is the same address A, will it need to be confirmed first for the second transaction to follow through, because the input of the second transaction is A?</p>

<p>In this example I used amounts to make sure there's "enough" bitcoin for each transaction separately (since if you have 1 BTC and you try to send it twice intuitively see why it shouldn't work).</p>

<p>Assume no extra addresses are generated automatically by the wallet to handle it. I'm talking about this specific re-use of addresses scenario.</p>

<transactions><transaction-fees><confirmations><output><transaction-input>
Can a low fee unconfirmed transaction prevent confirmations of following transactions?
Ahia Cohen
# Can a low fee unconfirmed transaction prevent confirmations of following transactions?

(Asked by: username_0 on 2017-12-08)

To be more precise, consider the following situation:

1. Address A gets an input of 4 BTC.
2. You try to make a transaction from A to B with 1 BTC and a very low fee, which means its unconfirmed for a long while. The transaction's output are B and A (to account for the change of ~3 BTC after fees)
3. Before waiting for the previous transaction to be confirmed, you send again from A to B, this time you send 2 BTC with a higher fee, hoping it'll be confirmed fast.

My question is, since the output of the first transaction is the same address A, will it need to be confirmed first for the second transaction to follow through, because the input of the second transaction is A?

In this example I used amounts to make sure there's "enough" bitcoin for each transaction separately (since if you have 1 BTC and you try to send it twice intuitively see why it shouldn't work).

Assume no extra addresses are generated automatically by the wallet to handle it. I'm talking about this specific re-use of addresses scenario.

**Tags:** transactions, transaction-fees, confirmations, output, transaction-input


---

## 1 answers

### Answer by username_1 on 2017-12-08. Score: 2 | Accepted answer

Yes, if the second transaction spends the output of the first one, then #2 cannot be confirmed until after #1 is confirmed. (Though they can be confirmed in a single block, as long as #1 appears before #2 in that block, in which case the confirmations are effectively simultaneous.)

Most miners will consider transactions on a "child pays for parent" basis, so that a low fee for #1 could be compensated by a high fee in #2. The two transactions would be considered as a single "lump" with their combined fee, and a miner would confirm them if the combined lump pays a higher fee than the next most lucrative transaction (or lump) that could fill that space.

> **Comments:**
> **username_0**: 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?  
> **username_1**: @username_0 (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.  
> **username_1**: @username_0: (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.  
> **username_0**: 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).  
> **username_1**: @username_0: 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.  
> **username_0**: 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.  
> **username_1**: @username_0: 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.  

---

