<p>In principle this will work, but Bitcoin Core by default limits such chains: a transaction will not enter a Bitcoin Core node's mempool if it has more than 25 ancestors, or more than 25 descendants.</p>
<p>There are downsides to long transaction chains in the face of swinging feerates. Firstly, if the feerates rise, you cannot simply bump a single more urgent transaction—you'd have to bump it and all of its ancestors. Secondly, transaction chaining is somewhat <a href="https://bitcoin.stackexchange.com/q/49517/5406">incompatible with RBF</a>—bumping any of the prior transactions breaks all the later transactions because their inputs cease to exist and you have to pay enough fees to replace the fees of all the descendant transactions to get admitted to the mempool. Thirdly, if a node's mempool runs out of space, it'll drop low feerate transactions first. If one of your prior transactions gets dropped, the entire chain following it will be inadmissible to (default) mempools until we get something like package relay, or the mempool relaxes to a level where the transaction can be rebroadcast.</p>
<p>Ways to work around this are to always bump the parent transactions to the targeted feerate of follow-up transactions (which is not trivial to calculate and may lead to overpayment in the case of two children to the same ancestors), or to always have exactly one output from which you chain.</p>
<p>In the case that you have enough transaction volume to warrant transaction chaining, I would recommend that you rather use <a href="https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb" rel="nofollow noreferrer">payment batching</a>: delay withdrawals (or other payments) by a few minutes, but then do multiple in a single transaction. Payment batching has a much smaller blockweight footprint per payment (and thus lower fees per payment), makes UTXO management much easier, because you need fewer inputs per payment, have less funds in flight because you only create a single change output per batch instead of per payment, and can maybe forgo using unconfirmed inputs altogether, which allows you to use RBF and CPFP to bump transactions when they get delayed even when you start them off with much lower feerates.
Additionally, while chaining of transactions would start to break down due to the limits on ancestry sizes, payment batching just gets more efficient with higher volume.</p>
<blockquote>
<p>Secondly, will the chained transactions be mined at the same block?</p>
</blockquote>
<p>Yes, if the child transaction pays a higher feerate than its ancestors, they would likely be picked as a package based on the descendant feerate. If later transactions pay the same or a lower feerate, a parent may be included without children.</p>

CC BY-SA 4.0
2021-03-31T15:38:16.743Z
Thank you so much for the detailed explanation!
Payment batching makes a lot of sense. I can then wait for the transaction to be confirmed and use it's confirmed UTXO as input.
Are there any limitations for the max ammount of inputs or outputs I should pay attention to?
abianchessi
CC BY-SA 4.0
2021-03-31T15:40:34.450Z
Transactions can have hundreds of inputs and outputs. They're mostly limited by the standard transaction weight limit of 400,000 weight units (which allows more than 1,400 P2WPKH inputs, or over 2,000 outputs). I added a link to a blog post about batching with more considerations and details.
Murch
CC BY-SA 4.0
2021-03-31T14:36:28.727Z
2021-04-16T03:24:48.823Z
2021-04-16T03:24:48.823Z
Murch
<p>The problem of double-spending is one of the main concerns of any cryptocurrency developer. This refers to the occurrence of a person spending a cryptocurrency balance more than once, resulting in a discrepancy between the spending record and the amount of cryptocurrency available, as well as how it is distributed. and double check your security as well. Reference:
<a href="https://learncrypto.com/knowledge-base/basics/cryptocurrency-scarcity-trust-in-modern-money" rel="nofollow noreferrer">https://learncrypto.com/knowledge-base/basics/cryptocurrency-scarcity-trust-in-modern-money</a></p>

CC BY-SA 4.0
2021-04-19T06:59:19.997Z
2021-04-19T06:59:19.997Z
themarkwilkinson
<p>Is it okay to chain and broadcast multiple unconfirmed transactions?<br />
For example: I have two confirmed UTXOs <code>UC1</code> and <code>UC2</code>. Using both as inputs, I then create and broadcast transaction <code>T1</code>, which outputs <code>UT1</code>. Then, using <code>UT1</code> and another confirmed UTXO, <code>UC3</code>, I create and broadcast <code>T2</code>, which outputs <code>UT2</code>. I keep track of the last unconfirmed UTXO from the transactions I built and keep building and broadcasting new ones.</p>
<p>Secondly, will the chained transactions be mined at the same block?</p>

<unconfirmed-transactions><child-pays-for-parent>
Is it okay to chain multiple unconfirmed transactions?
abianchessi
# Is it okay to chain multiple unconfirmed transactions?

(Asked by: username_0 on 2021-03-31)

Is it okay to chain and broadcast multiple unconfirmed transactions?  
For example: I have two confirmed UTXOs `UC1` and `UC2`. Using both as inputs, I then create and broadcast transaction `T1`, which outputs `UT1`. Then, using `UT1` and another confirmed UTXO, `UC3`, I create and broadcast `T2`, which outputs `UT2`. I keep track of the last unconfirmed UTXO from the transactions I built and keep building and broadcasting new ones.

Secondly, will the chained transactions be mined at the same block?

**Tags:** unconfirmed-transactions, child-pays-for-parent


---

## 2 answers

### Answer by username_1 on 2021-03-31. Score: 1 | Accepted answer

In principle this will work, but Bitcoin Core by default limits such chains: a transaction will not enter a Bitcoin Core node's mempool if it has more than 25 ancestors, or more than 25 descendants.

There are downsides to long transaction chains in the face of swinging feerates. Firstly, if the feerates rise, you cannot simply bump a single more urgent transaction—you'd have to bump it and all of its ancestors. Secondly, transaction chaining is somewhat [incompatible with RBF](https://bitcoin.stackexchange.com/q/49517/5406)—bumping any of the prior transactions breaks all the later transactions because their inputs cease to exist and you have to pay enough fees to replace the fees of all the descendant transactions to get admitted to the mempool. Thirdly, if a node's mempool runs out of space, it'll drop low feerate transactions first. If one of your prior transactions gets dropped, the entire chain following it will be inadmissible to (default) mempools until we get something like package relay, or the mempool relaxes to a level where the transaction can be rebroadcast.

Ways to work around this are to always bump the parent transactions to the targeted feerate of follow-up transactions (which is not trivial to calculate and may lead to overpayment in the case of two children to the same ancestors), or to always have exactly one output from which you chain.

In the case that you have enough transaction volume to warrant transaction chaining, I would recommend that you rather use [payment batching](https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb): delay withdrawals (or other payments) by a few minutes, but then do multiple in a single transaction. Payment batching has a much smaller blockweight footprint per payment (and thus lower fees per payment), makes UTXO management much easier, because you need fewer inputs per payment, have less funds in flight because you only create a single change output per batch instead of per payment, and can maybe forgo using unconfirmed inputs altogether, which allows you to use RBF and CPFP to bump transactions when they get delayed even when you start them off with much lower feerates.
Additionally, while chaining of transactions would start to break down due to the limits on ancestry sizes, payment batching just gets more efficient with higher volume.

> Secondly, will the chained transactions be mined at the same block?

Yes, if the child transaction pays a higher feerate than its ancestors, they would likely be picked as a package based on the descendant feerate. If later transactions pay the same or a lower feerate, a parent may be included without children.

> **Comments:**
> **username_0**: Thank you so much for the detailed explanation! Payment batching makes a lot of sense. I can then wait for the transaction to be confirmed and use it's confirmed UTXO as input. Are there any limitations for the max ammount of inputs or outputs I should pay attention to?  
> **username_1**: Transactions can have hundreds of inputs and outputs. They're mostly limited by the standard transaction weight limit of 400,000 weight units (which allows more than 1,400 P2WPKH inputs, or over 2,000 outputs). I added a link to a blog post about batching with more considerations and details.  

---

### Answer by username_2 on 2021-04-19. Score: 0

The problem of double-spending is one of the main concerns of any cryptocurrency developer. This refers to the occurrence of a person spending a cryptocurrency balance more than once, resulting in a discrepancy between the spending record and the amount of cryptocurrency available, as well as how it is distributed. and double check your security as well. Reference:
<https://learncrypto.com/knowledge-base/basics/cryptocurrency-scarcity-trust-in-modern-money>


---

