<blockquote>
  <p>How do I check and design a transaction so that I can send 3 BTC to User 2?</p>
</blockquote>

<p>You reference the 5 BTC unconfirmed UTXO for your next transaction and pay 3 BTCs to User 2 and 2 BTC back to yourself.</p>

<blockquote>
  <p>Can I chain unconfirmed transactions? </p>
</blockquote>

<p>Yes, you can. </p>

<blockquote>
  <p>Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?</p>
</blockquote>

<p>Yes, there is a possibility. The latter transaction will not be discarded, it will be in another node's orphan tx set so as long as that limit has not been met. So there's also the possibility that some node's orphan tx set is full and your orphan tx will get rejected outright. </p>

<p>Tx1 (unconfirmed, accepted) &lt;- Tx2 (unconfirmed, not yet visible) &lt;- Tx3 (unconfirmed, accepted &amp;&amp; orphaned)</p>

<p>The above transaction chain is a valid chain of unconfirmed transaction.</p>

<blockquote>
  <p>Finally, is there a better way to do this?</p>
</blockquote>

<p>Not quite. The recipient can use CPFP to bump the fees, so the transaction fee that pays for the entire transaction chain becomes greater. That increases the probability of immediate confirmation. Otherwise, you as the payer can use RBF to bump the fees. </p>

<blockquote>
  <p>For an outgoing bitcoin account that only makes payments to users, what would be the best practice? </p>
</blockquote>

<p>Only pay from confirmed transactions, otherwise pay sufficient transaction fees which results in probable immediate confirmation. You as the payer would still have the opportunity to bump the fees with RBF to provide better user experience. Or you may insist your users to use CPFP to accelerate their receipts.</p>

<blockquote>
  <p>Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?</p>
</blockquote>

<p>Exchanges don't really care about the speed at which recipient receives their fees, they usually pay a decent transaction fee so that you'd receive your transaction in "due course". </p>

CC BY-SA 3.0
2016-12-14T01:50:01.627Z
Thank you for the detailed answer.

However, I find that exchanges post transactions as soon as I've requested the payout, and I've never seen an unconfirmed output being used as an input in a tx. Is there some efficient way of running a payout system that I'm not aware of?
hrishioa
CC BY-SA 3.0
2016-12-14T03:15:13.277Z
I suppose the reason why exchanges can manage this is because of volume or most traded coins are simply between account within an exchange, so actual blockchain transactions are not required.
rny
CC BY-SA 3.0
2016-12-14T03:40:01.323Z
My thoughts exactly at first, but looking at exchanges like Coinbase I'm not sure if they're matching orders between users or sending bitcoin from a few hot wallets. The former would be quite hard for a low-volume exchange I'd imagine.
hrishioa
CC BY-SA 3.0
2016-12-12T03:58:13.247Z
2016-12-12T03:58:13.247Z
rny
<p>I'm currently working on a system that provides payouts to users from a bitcoin address as they 'burn' other assets on the site (think something like <a href="http://shapeshift.io" rel="nofollow noreferrer">ShapeShift</a>, where you pay someone BTC to get some other cryptocoin, and you pay this coin back to get BTC).</p>

<p>I'm using public apis to build and send raw transactions using <a href="https://bitcoinjs.org/" rel="nofollow noreferrer">bitcoinjs</a>. However, I have the issue that I sometimes need to wait for previous transactions to confirm before I can send more out. This will often involve bitcoins that will - no matter the result of the confirmation - be mine.</p>

<p>Here's an example. I have 10 BTC, and I have posted a tx to User 1, sending him 5 BTC and 5 BTC back to myself. Now I am sure that I have 5 BTC in my account (regardless of whether the tx confirms) - but this isn't easy to confirm for me, especially when multiple such txs get chained and a lot more inputs and outputs get involved. How do I check and design a transaction so that I can send 3 BTC to User 2?</p>

<p>Can I chain unconfirmed transactions? I understand this would be dangerous if any of the transactions failed (insufficient fee, corrupt data, etc). Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?</p>

<p>Finally, is there a better way to do this? For an outgoing bitcoin account that only makes payments to users, what would be the best practice? Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?</p>

<p>I understand there is a similar question <a href="https://bitcoin.stackexchange.com/questions/13085/how-does-a-wallet-use-unconfirmed-outputs-as-inputs-after-unconfirmed-transactio">here</a>, but it does not discuss transaction ordering, and my concern is primarily about setting up an outgoing Payment system by which I can send multiple outgoing transactions per block as payouts.</p>

<transactions><unconfirmed-transactions>
Chaining unconfirmed raw transactions
hrishioa
# Chaining unconfirmed raw transactions

(Asked by: username_0 on 2016-12-11)

I'm currently working on a system that provides payouts to users from a bitcoin address as they 'burn' other assets on the site (think something like [ShapeShift](http://shapeshift.io), where you pay someone BTC to get some other cryptocoin, and you pay this coin back to get BTC).

I'm using public apis to build and send raw transactions using [bitcoinjs](https://bitcoinjs.org/). However, I have the issue that I sometimes need to wait for previous transactions to confirm before I can send more out. This will often involve bitcoins that will - no matter the result of the confirmation - be mine.

Here's an example. I have 10 BTC, and I have posted a tx to User 1, sending him 5 BTC and 5 BTC back to myself. Now I am sure that I have 5 BTC in my account (regardless of whether the tx confirms) - but this isn't easy to confirm for me, especially when multiple such txs get chained and a lot more inputs and outputs get involved. How do I check and design a transaction so that I can send 3 BTC to User 2?

Can I chain unconfirmed transactions? I understand this would be dangerous if any of the transactions failed (insufficient fee, corrupt data, etc). Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?

Finally, is there a better way to do this? For an outgoing bitcoin account that only makes payments to users, what would be the best practice? Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?

I understand there is a similar question [here](https://bitcoin.stackexchange.com/questions/13085/how-does-a-wallet-use-unconfirmed-outputs-as-inputs-after-unconfirmed-transactio), but it does not discuss transaction ordering, and my concern is primarily about setting up an outgoing Payment system by which I can send multiple outgoing transactions per block as payouts.

**Tags:** transactions, unconfirmed-transactions


---

## 1 answers

### Answer by username_1 on 2016-12-12. Score: 3 | Accepted answer

> How do I check and design a transaction so that I can send 3 BTC to User 2?

You reference the 5 BTC unconfirmed UTXO for your next transaction and pay 3 BTCs to User 2 and 2 BTC back to yourself.

> Can I chain unconfirmed transactions?

Yes, you can.

> Setting this aside, would there be a possibility that the transactions aren't mined in the order they are broadcasted - or that a latter transaction is discarded because a former one does not exist in the chain yet?

Yes, there is a possibility. The latter transaction will not be discarded, it will be in another node's orphan tx set so as long as that limit has not been met. So there's also the possibility that some node's orphan tx set is full and your orphan tx will get rejected outright.

Tx1 (unconfirmed, accepted) <- Tx2 (unconfirmed, not yet visible) <- Tx3 (unconfirmed, accepted && orphaned)

The above transaction chain is a valid chain of unconfirmed transaction.

> Finally, is there a better way to do this?

Not quite. The recipient can use CPFP to bump the fees, so the transaction fee that pays for the entire transaction chain becomes greater. That increases the probability of immediate confirmation. Otherwise, you as the payer can use RBF to bump the fees.

> For an outgoing bitcoin account that only makes payments to users, what would be the best practice?

Only pay from confirmed transactions, otherwise pay sufficient transaction fees which results in probable immediate confirmation. You as the payer would still have the opportunity to bump the fees with RBF to provide better user experience. Or you may insist your users to use CPFP to accelerate their receipts.

> Would it be useful to split the account into multiple sending accounts - how is this done on existing systems like exchanges?

Exchanges don't really care about the speed at which recipient receives their fees, they usually pay a decent transaction fee so that you'd receive your transaction in "due course".

> **Comments:**
> **username_0**: Thank you for the detailed answer.  However, I find that exchanges post transactions as soon as I've requested the payout, and I've never seen an unconfirmed output being used as an input in a tx. Is there some efficient way of running a payout system that I'm not aware of?  
> **username_1**: I suppose the reason why exchanges can manage this is because of volume or most traded coins are simply between account within an exchange, so actual blockchain transactions are not required.  
> **username_0**: My thoughts exactly at first, but looking at exchanges like Coinbase I'm not sure if they're matching orders between users or sending bitcoin from a few hot wallets. The former would be quite hard for a low-volume exchange I'd imagine.  

---

