<blockquote>
  <p>Is the wallet using unconfirmed outputs as inputs here?</p>
</blockquote>

<p>Yes.</p>

<blockquote>
  <p>If so, how is it doing this</p>
</blockquote>

<p>Except for coinbase transactions, transactions are independent of blocks. A transaction spending an unconfirmed input looks exactly the same as a transaction spending a confirmed input.</p>

<p>It's safe for Bitcoin-Qt to spend unconfirmed change because it knows that the input is valid and will be confirmed at some point (though probably slowly). It would not be safe for Bitcoin-Qt to spend unconfirmed inputs that it did not itself create because they might never confirm, resulting in permanently tied-up funds. (Very old versions of Bitcoin made this mistake, but it was corrected after widespread issues.)</p>

<blockquote>
  <p>how can I do it using raw transactions?</p>
</blockquote>

<p>You can create the transaction with <code>createrawtransaction</code> normally, but you'll need to give <code>signrawtransaction</code> some extra info about the unconfirmed transaction in its second parameter.</p>

CC BY-SA 3.0
2013-09-03T02:24:43.800Z
createrawtransaction does support spending unconfirmed inputs; see https://gist.github.com/gavinandresen/3966071#file-twoofthree-sh-L42  for an example.
gavinandresen
CC BY-SA 3.0
2013-09-03T04:33:33.313Z
@gavinandresen Looking into it more, it seems to me that we're both wrong. In your example, `createrawtransaction` doesn't actually look at the provided `redeemScript` or `scriptPubKey` AFAICT. `createrawtransaction` uses whatever data you give it, and it doesn't even use the block database. `signrawtransaction` does need `redeemScript` and `scriptPubKey` for unconfirmed transactions.
theymos
CC BY-SA 3.0
2013-09-02T23:16:43.290Z
2013-09-03T04:38:00.940Z
2013-09-03T04:38:00.940Z
theymos
<p>It looks like Bitcoin QT is able to reference it's own unconfirmed transactions, which is kind of dangerous. Consider this: </p>

<p>The first transaction (A to B) might arrive in the block chain after the second (C to ...) or it might not arrive at all. In this case, the second transaction will not go through because it won't be valid until the first one happens. Even though the second transaction exists within Bitcoin QT, it probably doesn't get sent out until the first goes through.</p>

<p>If you want to do this with raw transactions, you can create both transactions at the same time, just know that the second one will be invalid (and thus rejected by the block chain) until the first one goes through. </p>

CC BY-SA 3.0
2013-09-03T16:25:30.347Z
"The first transaction (A to B) might arrive in the block chain after the second"... I think you need to clarify this... the 2nd transaction would never be included in a block unless the 1st one were in the same or earlier block
RentFree
CC BY-SA 3.0
2013-09-03T18:55:57.283Z
@RentFree Thanks for the clarification. Yes, the 2nd transaction wouldn't actually make it "in" the block chain because it would be invalid without the first.
John Henry
CC BY-SA 3.0
2013-09-02T18:10:38.687Z
2013-09-02T18:10:38.687Z
John Henry
<p>Bitcoin-QT treating the change as okay to spend depends on the client itself having created it within itself. Creating transaction with createrawtransaction change as unconfirmed. Bu sendfrom not.</p>

CC BY-SA 3.0
2013-09-03T07:59:54.190Z
2013-09-03T07:59:54.190Z
Ozan Yurtseven
<p>My understanding is that technically the first confirmation is against your own blockchain copy.</p>

<p>So although the transaction may not be confirmed in a block, the client is aware that this change transaction is unlikely to be rejected.</p>

<p>In fact logically it cannot be rejected if the transaction was created correctly.</p>

CC BY-SA 3.0
2013-09-03T16:26:19.600Z
It could get rejected due to not enough transaction fee
RentFree
CC BY-SA 3.0
2014-04-25T18:51:12.107Z
It could get rejected if it is double-spended and the double-spending transaction has higher fee
Maciej Mączko
CC BY-SA 3.0
2013-09-02T22:39:58.200Z
2013-09-02T22:39:58.200Z
T9b
<p>I have 10 btc on address A.</p>

<p>Using raw transaction, I send 5btc from A to B and set the change address as A itself. Now because the transaction from A to B is not confirmed I can't spend the remaining 5 btc.</p>

<p>But I saw that the QT wallet can do this. Ex:</p>

<p>I have 10 btc on address A. I send 5btc to B. The wallet creates a new address C and sets it as the change address. Then I try using the 5 btc on the wallet and it works. It allows me to send from address C. </p>

<p>1) Is the wallet using unconfirmed outputs as inputs here?</p>

<p>2) If so, how is it doing this and how can I do it using raw transactions?</p>

<p>3) If not, what's going on here?</p>

<transactions><confirmations><unconfirmed-transactions>
How does a wallet use unconfirmed outputs as inputs after unconfirmed transactions?
Emre K.
# How does a wallet use unconfirmed outputs as inputs after unconfirmed transactions?

(Asked by: username_0 on 2013-09-02)

I have 10 btc on address A.

Using raw transaction, I send 5btc from A to B and set the change address as A itself. Now because the transaction from A to B is not confirmed I can't spend the remaining 5 btc.

But I saw that the QT wallet can do this. Ex:

I have 10 btc on address A. I send 5btc to B. The wallet creates a new address C and sets it as the change address. Then I try using the 5 btc on the wallet and it works. It allows me to send from address C.

1) Is the wallet using unconfirmed outputs as inputs here?

2) If so, how is it doing this and how can I do it using raw transactions?

3) If not, what's going on here?

**Tags:** transactions, confirmations, unconfirmed-transactions


---

## 4 answers

### Answer by username_1 on 2013-09-02. Score: 3

> Is the wallet using unconfirmed outputs as inputs here?

Yes.

> If so, how is it doing this

Except for coinbase transactions, transactions are independent of blocks. A transaction spending an unconfirmed input looks exactly the same as a transaction spending a confirmed input.

It's safe for Bitcoin-Qt to spend unconfirmed change because it knows that the input is valid and will be confirmed at some point (though probably slowly). It would not be safe for Bitcoin-Qt to spend unconfirmed inputs that it did not itself create because they might never confirm, resulting in permanently tied-up funds. (Very old versions of Bitcoin made this mistake, but it was corrected after widespread issues.)

> how can I do it using raw transactions?

You can create the transaction with `createrawtransaction` normally, but you'll need to give `signrawtransaction` some extra info about the unconfirmed transaction in its second parameter.

> **Comments:**
> **username_2**: createrawtransaction does support spending unconfirmed inputs; see https://gist.github.com/username_2/3966071#file-twoofthree-sh-L42  for an example.  
> **username_1**: @username_2 Looking into it more, it seems to me that we're both wrong. In your example, `createrawtransaction` doesn't actually look at the provided `redeemScript` or `scriptPubKey` AFAICT. `createrawtransaction` uses whatever data you give it, and it doesn't even use the block database. `signrawtransaction` does need `redeemScript` and `scriptPubKey` for unconfirmed transactions.  

---

### Answer by username_3 on 2013-09-02. Score: 1

It looks like Bitcoin QT is able to reference it's own unconfirmed transactions, which is kind of dangerous. Consider this:

The first transaction (A to B) might arrive in the block chain after the second (C to ...) or it might not arrive at all. In this case, the second transaction will not go through because it won't be valid until the first one happens. Even though the second transaction exists within Bitcoin QT, it probably doesn't get sent out until the first goes through.

If you want to do this with raw transactions, you can create both transactions at the same time, just know that the second one will be invalid (and thus rejected by the block chain) until the first one goes through.

> **Comments:**
> **username_4**: "The first transaction (A to B) might arrive in the block chain after the second"... I think you need to clarify this... the 2nd transaction would never be included in a block unless the 1st one were in the same or earlier block  
> **username_3**: @username_4 Thanks for the clarification. Yes, the 2nd transaction wouldn't actually make it "in" the block chain because it would be invalid without the first.  

---

### Answer by username_5 on 2013-09-03. Score: 1

Bitcoin-QT treating the change as okay to spend depends on the client itself having created it within itself. Creating transaction with createrawtransaction change as unconfirmed. Bu sendfrom not.


---

### Answer by username_6 on 2013-09-02. Score: 0

My understanding is that technically the first confirmation is against your own blockchain copy.

So although the transaction may not be confirmed in a block, the client is aware that this change transaction is unlikely to be rejected.

In fact logically it cannot be rejected if the transaction was created correctly.

> **Comments:**
> **username_4**: It could get rejected due to not enough transaction fee  
> **username_7**: It could get rejected if it is double-spended and the double-spending transaction has higher fee  

---

