<p>You are technically able to do this but it is strongly not recommended. A transaction can spend the output of another transaction so long as the parent transaction is known by the node in question, however this is quite fragile. </p>

<p>Bitcoin transactions back reference by TXID, a cryptographic hash of the previous one being spent. Due to a property known as transaction malleability it is currently possible for this TXID to change spontaneously when it it broadcast through the network, due to some nodes running custom code which mutates transactions in specific ways. If you build a long chain of unconfirmed transactions and one early on is mutated, all subsequent transactions can suddenly appear to spend outputs which don't exist anymore and are effectively invalidated. It's difficult to produce safe software which can handle this situation with this as there's a lot of edge cases that need dealing with. </p>

<p>If you need to make a number of payments to many parties in a short period, many large providers will split their outputs up ahead of time to avoid ever needing to spend unconfirmed change. When they receive a 100 BTC output they might break it into four 25 BTC chunks paying themselves, which will allow them to pay four people when required without needing to ever attempt to spend unconfirmed change. Some delicate balancing is required here, if you have too many outputs in your wallet the fees increase dramatically and the software will become slow. </p>

CC BY-SA 3.0
2015-09-27T17:36:57.297Z
Thanks, friend. This is great info. Looks like I'm going to have to run a background routine to do exactly what you suggested: preemptively break down larger, unspent outputs into smaller ones that are confirmed and ready for use.
Festus Martingale
CC BY-SA 3.0
2015-09-26T19:39:56.733Z
2015-09-26T20:50:11.190Z
2015-09-26T20:50:11.190Z
Claris
<p>Consider a custom program which will occasionally need to send out bitcoin to users to whom I owe money.</p>

<p>Let's say I have 100 unspent BTC at address ADDR_A.</p>

<p>UserX demands payment of 1 BTC to ADDR_X. I honor the request, spending my 100 BTC from ADDR_A, directing 1 BTC to ADDR_X and 99 to ADDR_CHANGE_A. (Let's ignore the impact of transaction fees in this contrived example.) The raw transaction is submitted via a public Bitcoin API like Insight.</p>

<p>Five seconds later UserY demands payment of 1 BTC to ADDR_Y. I want to use ADDR_CHANGE_A as an input to facilitate the transaction.</p>

<p>Question: Can I use my newly created ADDR_CHANGE_A address as an input given that the original change output that targeted ADDR_CHANGE_A has not yet confirmed? Other material on this site indicates that the transaction should work but I'd like to understand WHY it works. Assuming that the public Bitcoin API receives my transaction that uses ADDR_CHANGE_A as an input, but has no knowledge that ADDR_CHANGE_A was used as an output in a prior transaction which took place only seconds earlier, wouldn't it balk at my attempt to spend from ADDR_CHANGE_A?</p>

CC BY-SA 3.0
2015-09-26T20:11:20.070Z
WHY it works is actually quite simple: it's all just transactions linked together. Whether they end up in the same block or not doesn't matter. The reason why it's actually highly problematic is much more complicated. Bitcoin (the stackexchange user) explains that very well below.
Jannes
CC BY-SA 3.0
2015-09-27T17:38:04.807Z
Thanks. I'll follow his advice. Glad I asked this question early on before writing too much code.
Festus Martingale
<unconfirmed-transactions><spending>
Spending unconfirmed output from a change address
Festus Martingale
# Spending unconfirmed output from a change address

(Asked by: username_0 on 2015-09-26)

Consider a custom program which will occasionally need to send out bitcoin to users to whom I owe money.

Let's say I have 100 unspent BTC at address ADDR\_A.

UserX demands payment of 1 BTC to ADDR\_X. I honor the request, spending my 100 BTC from ADDR\_A, directing 1 BTC to ADDR\_X and 99 to ADDR\_CHANGE\_A. (Let's ignore the impact of transaction fees in this contrived example.) The raw transaction is submitted via a public Bitcoin API like Insight.

Five seconds later UserY demands payment of 1 BTC to ADDR\_Y. I want to use ADDR\_CHANGE\_A as an input to facilitate the transaction.

Question: Can I use my newly created ADDR\_CHANGE\_A address as an input given that the original change output that targeted ADDR\_CHANGE\_A has not yet confirmed? Other material on this site indicates that the transaction should work but I'd like to understand WHY it works. Assuming that the public Bitcoin API receives my transaction that uses ADDR\_CHANGE\_A as an input, but has no knowledge that ADDR\_CHANGE\_A was used as an output in a prior transaction which took place only seconds earlier, wouldn't it balk at my attempt to spend from ADDR\_CHANGE\_A?

**Tags:** unconfirmed-transactions, spending

> **Comments:**
> **username_1**: WHY it works is actually quite simple: it's all just transactions linked together. Whether they end up in the same block or not doesn't matter. The reason why it's actually highly problematic is much more complicated. Bitcoin (the stackexchange user) explains that very well below.  
> **username_0**: Thanks. I'll follow his advice. Glad I asked this question early on before writing too much code.  

---

## 1 answers

### Answer by username_2 on 2015-09-26. Score: 5 | Accepted answer

You are technically able to do this but it is strongly not recommended. A transaction can spend the output of another transaction so long as the parent transaction is known by the node in question, however this is quite fragile.

Bitcoin transactions back reference by TXID, a cryptographic hash of the previous one being spent. Due to a property known as transaction malleability it is currently possible for this TXID to change spontaneously when it it broadcast through the network, due to some nodes running custom code which mutates transactions in specific ways. If you build a long chain of unconfirmed transactions and one early on is mutated, all subsequent transactions can suddenly appear to spend outputs which don't exist anymore and are effectively invalidated. It's difficult to produce safe software which can handle this situation with this as there's a lot of edge cases that need dealing with.

If you need to make a number of payments to many parties in a short period, many large providers will split their outputs up ahead of time to avoid ever needing to spend unconfirmed change. When they receive a 100 BTC output they might break it into four 25 BTC chunks paying themselves, which will allow them to pay four people when required without needing to ever attempt to spend unconfirmed change. Some delicate balancing is required here, if you have too many outputs in your wallet the fees increase dramatically and the software will become slow.

> **Comments:**
> **username_0**: Thanks, friend. This is great info. Looks like I'm going to have to run a background routine to do exactly what you suggested: preemptively break down larger, unspent outputs into smaller ones that are confirmed and ready for use.  

---

