<p>Many wallet implementations prefer spending confirmed inputs over unconfirmed inputs. There are multiple reasons for this preference:</p>

<ol>
<li><p>Bitcoin Core (and perhaps other software as well) does not propagate chains of unconfirmed transactions beyond a certain depth. If you continuously reuse unconfirmed UTXOs, eventually your transactions will not be seen on the network until some predecessors confirm.</p></li>
<li><p>Transactions using unconfirmed inputs are susceptible to become invalid due to a parent transaction being replaced or doublespent.</p></li>
<li><p>A transaction building on top of an unconfirmed change cannot be confirmed until the parent transaction is confirmed. This dependency is used by child-pays-for-parent transactions positively to increase the priority of the parent transaction, but can also be a handicap, when a low fee transaction essentially puts the onus on the recipient to bump the transaction in order to gain access to their funds.</p></li>
</ol>

CC BY-SA 3.0
2018-04-16T00:07:29.347Z
2018-04-16T00:07:29.347Z
Murch
<p>If you spend zero conf transactions, the spend will not confirm until the transaction they source confirms. You can end up with a chain of transactions all waiting for the first one to confirm. Computers are ok with this, but people get confused. :)</p>

CC BY-SA 3.0
2018-01-04T17:21:23.893Z
is it the only reason? Because what I that if you received unconfirmed transaction you can push it by re-spending that transaction with higher fee.
Tailer
CC BY-SA 3.0
2018-01-04T21:35:28.663Z
This is a different question, but in brief, there are ways to push the transactions along (child pays for parent (cpfp), replace by fee (rbf), miner accelerators).
harrym
CC BY-SA 3.0
2018-01-04T13:11:35.207Z
2018-01-04T13:11:35.207Z
harrym
<p>I know that selecting transactions with confirmations first are much better than spending transactions with 0 confirmations direct. </p>

<p>But why is that? </p>

<unconfirmed-transactions><coin-selection>
coin selection - why selecting transactions with confirmations first better
Tailer
# coin selection - why selecting transactions with confirmations first better

(Asked by: username_0 on 2018-01-04)

I know that selecting transactions with confirmations first are much better than spending transactions with 0 confirmations direct.

But why is that?

**Tags:** unconfirmed-transactions, coin-selection


---

## 2 answers

### Answer by username_1 on 2018-04-16. Score: 2 | Accepted answer

Many wallet implementations prefer spending confirmed inputs over unconfirmed inputs. There are multiple reasons for this preference:

1. Bitcoin Core (and perhaps other software as well) does not propagate chains of unconfirmed transactions beyond a certain depth. If you continuously reuse unconfirmed UTXOs, eventually your transactions will not be seen on the network until some predecessors confirm.
2. Transactions using unconfirmed inputs are susceptible to become invalid due to a parent transaction being replaced or doublespent.
3. A transaction building on top of an unconfirmed change cannot be confirmed until the parent transaction is confirmed. This dependency is used by child-pays-for-parent transactions positively to increase the priority of the parent transaction, but can also be a handicap, when a low fee transaction essentially puts the onus on the recipient to bump the transaction in order to gain access to their funds.


---

### Answer by username_2 on 2018-01-04. Score: 1

If you spend zero conf transactions, the spend will not confirm until the transaction they source confirms. You can end up with a chain of transactions all waiting for the first one to confirm. Computers are ok with this, but people get confused. :)

> **Comments:**
> **username_0**: is it the only reason? Because what I that if you received unconfirmed transaction you can push it by re-spending that transaction with higher fee.  
> **username_2**: This is a different question, but in brief, there are ways to push the transactions along (child pays for parent (cpfp), replace by fee (rbf), miner accelerators).  

---

