<p>The protocol and the standard client allow you to spend your own unconfirmed change. Multibit didn't allow this, but I believe it's a recently/soon added feature.</p>

<p>When constructing your transaction manually there is little advantage to choosing confirmed outputs.</p>

<p>If you do want to split your outputs, you can do it with a sendmany transaction. The Bitcoin-qt GUI allows you to do this ("Add Recipient"), which can scale to several outputs. For a larger number of outputs you can generate the command programmatically and issue it with the command line.</p>

<p>Bitcoin-qt does not allow you to pay an address multiple times in the same transaction. There seems to be little justification for that, and it may be possible with the raw transaction API. Alternatively, you can generate several addresses and split the amount between them.</p>

CC BY-SA 3.0
2012-12-19T09:48:57.343Z
2012-12-19T10:13:49.907Z
2012-12-19T10:13:49.907Z
Meni Rosenfeld
<p>I have a wallet that pays lots of small amounts in the range of 0.x to 5 BTC.
I filled the wallet with one transaction of 50 BTC, so there is only one large input contained.
Now when i transfer 0.5 BTC anywhere, the transaction has two outputs - 0.5 for the receiver and 49.5 change.
Problem is that as long as this transaction is not confirmed the wallet is more or less blocked, as it only contains 49.5 <strong>unconfirmed</strong> balance.</p>

<p>So basically I end up with one transaction per block, as i need to wait for the change to be confirmed until i can create the next tx.</p>

<p><strong>Edit:</strong>
Note that I am using the rawtransactions API and when constructing a transaction i only want to use confirmed outputs (from "listunspent" command) as inputs for the new tx.</p>

<p>What is the best way to split the big output in the wallet into something like e.g. 10*5.0 BTC?</p>

CC BY-SA 3.0
2012-12-19T09:00:22.523Z
I thought the Bitcoin-Qt client will let you spend your own change even if it has no confirmations.  Are you sure that you can't create another spend transaction?
Stephen Gornick
CC BY-SA 3.0
2012-12-19T09:10:11.717Z
Sorry, I was not fully clear with my question. I am using the rawtransactins API and when selecting outpoints for a transaction (from the "listunspent" command) I explicitly search for outpoints with >= 1 confirmation. But even if the original client will allow to spend unconfirmed change - Would it not take much longer to get confirmed?
TripleSpeeder
CC BY-SA 3.0
2012-12-19T09:49:24.023Z
@TripleSpeeder: Why would it take longer to confirm? In most cases, the transactions will be confirmed as soon as a block is found.
Meni Rosenfeld
CC BY-SA 3.0
2012-12-19T09:50:44.677Z
@TripleSpeeder: The standard term is "outputs".
Meni Rosenfeld
CC BY-SA 3.0
2012-12-19T10:03:07.330Z
@Meni: I always had the impression that using chains of unconfirmed transactions is quite risky. So if the first transaction does never get a confirmation for any reason, all transactions using the first transaction's change as input will also never confirm. So probably it will not take longer to get confirmed, but there is a higher risk involved. If this is the case I am surprised the original client allows that?
TripleSpeeder
CC BY-SA 3.0
2012-12-19T10:12:39.653Z
@TripleSpeeder: The standard client only allows spending your own change; it doesn't allow spending unconfirmed transactions from outside (that, too, is allowed by protocol however). I suppose this limitation is due to concerns such as those you described. I don't think the effect is very strong, though. In normal usage, spending unconfirmed coins will be rare even if allowed; so the crux of double-spending risk is with the last sender anyway.
Meni Rosenfeld
<wallet><confirmations><fragmentation>
How can i effectively split large outputs into smaller ones?
TripleSpeeder
# How can i effectively split large outputs into smaller ones?

(Asked by: username_0 on 2012-12-19)

I have a wallet that pays lots of small amounts in the range of 0.x to 5 BTC.
I filled the wallet with one transaction of 50 BTC, so there is only one large input contained.
Now when i transfer 0.5 BTC anywhere, the transaction has two outputs - 0.5 for the receiver and 49.5 change.
Problem is that as long as this transaction is not confirmed the wallet is more or less blocked, as it only contains 49.5 **unconfirmed** balance.

So basically I end up with one transaction per block, as i need to wait for the change to be confirmed until i can create the next tx.

**Edit:**
Note that I am using the rawtransactions API and when constructing a transaction i only want to use confirmed outputs (from "listunspent" command) as inputs for the new tx.

What is the best way to split the big output in the wallet into something like e.g. 10\*5.0 BTC?

**Tags:** wallet, confirmations, fragmentation

> **Comments:**
> **username_1**: I thought the Bitcoin-Qt client will let you spend your own change even if it has no confirmations.  Are you sure that you can't create another spend transaction?  
> **username_0**: Sorry, I was not fully clear with my question. I am using the rawtransactins API and when selecting outpoints for a transaction (from the "listunspent" command) I explicitly search for outpoints with >= 1 confirmation. But even if the original client will allow to spend unconfirmed change - Would it not take much longer to get confirmed?  
> **username_2**: @username_0: Why would it take longer to confirm? In most cases, the transactions will be confirmed as soon as a block is found.  
> **username_2**: @username_0: The standard term is "outputs".  
> **username_0**: @username_2: I always had the impression that using chains of unconfirmed transactions is quite risky. So if the first transaction does never get a confirmation for any reason, all transactions using the first transaction's change as input will also never confirm. So probably it will not take longer to get confirmed, but there is a higher risk involved. If this is the case I am surprised the original client allows that?  
> **username_2**: @username_0: The standard client only allows spending your own change; it doesn't allow spending unconfirmed transactions from outside (that, too, is allowed by protocol however). I suppose this limitation is due to concerns such as those you described. I don't think the effect is very strong, though. In normal usage, spending unconfirmed coins will be rare even if allowed; so the crux of double-spending risk is with the last sender anyway.  

---

## 1 answers

### Answer by username_2 on 2012-12-19. Score: 2 | Accepted answer

The protocol and the standard client allow you to spend your own unconfirmed change. Multibit didn't allow this, but I believe it's a recently/soon added feature.

When constructing your transaction manually there is little advantage to choosing confirmed outputs.

If you do want to split your outputs, you can do it with a sendmany transaction. The Bitcoin-qt GUI allows you to do this ("Add Recipient"), which can scale to several outputs. For a larger number of outputs you can generate the command programmatically and issue it with the command line.

Bitcoin-qt does not allow you to pay an address multiple times in the same transaction. There seems to be little justification for that, and it may be possible with the raw transaction API. Alternatively, you can generate several addresses and split the amount between them.


---

