<p>A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:</p>

<p><strong>Start with more UTXOs.</strong> Each UTXO can be used to create &lt;25 unconfirmed child transactions. So if you need to make <code>n</code> payments, you'll need at least <code>n/25</code> UTXOs to do so using this method.</p>

<p>However, you can definitely do this in a more cost-effective manner. As Murch mentioned, <strong>batch payments</strong> describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction. </p>

<p>Another option is to use the <strong>lightning network</strong> to send your payments. Lightning transactions are <em>extremely</em> cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.</p>

CC BY-SA 4.0
2020-02-19T07:02:12.287Z
Thanks for the answer! I was not aware of the possibility of batching transactions. This sounds like what I’m looking for. Is there a disadvantage to batching many transactions (say 100) together?
About the lightning network - wouldn’t that require the recipients of the payments to also be on the lightning network?
depqm
CC BY-SA 4.0
2020-02-18T21:03:47.340Z
2020-02-18T21:03:47.340Z
chytrik
<p>I want to build a service that requires sending many small bitcoin transactions to multiple wallets (like a faucet). </p>

<p>Since the transactions are small, the fees have to be kept small as well so it takes a while for them to be confirmed. </p>

<p>The system would need to send many transactions, which naturally creates long chains of unconfirmed transactions. If I understand it correctly, after 25 unconfirmed transactions the network starts rejecting new ones, and the system is basically stuck until the previous ones gets confirmed. </p>

<p>This limits the throughput of such a system to 25 transactions per confirmation time (which is at least a few hours given the low fees), making it completely unscalable.  </p>

<p>Given the above, is there a way to build a (somewhat) scalable service that can send many small transactions? (without having to manage many wallets)</p>

CC BY-SA 4.0
2020-02-18T19:06:26.350Z
Have you considered batching the payments?
Murch
<unconfirmed-transactions><scalability>
Problem caused by unconfirmed transaction chains
depqm
# Problem caused by unconfirmed transaction chains

(Asked by: username_0 on 2020-02-18)

I want to build a service that requires sending many small bitcoin transactions to multiple wallets (like a faucet).

Since the transactions are small, the fees have to be kept small as well so it takes a while for them to be confirmed.

The system would need to send many transactions, which naturally creates long chains of unconfirmed transactions. If I understand it correctly, after 25 unconfirmed transactions the network starts rejecting new ones, and the system is basically stuck until the previous ones gets confirmed.

This limits the throughput of such a system to 25 transactions per confirmation time (which is at least a few hours given the low fees), making it completely unscalable.

Given the above, is there a way to build a (somewhat) scalable service that can send many small transactions? (without having to manage many wallets)

**Tags:** unconfirmed-transactions, scalability

> **Comments:**
> **username_1**: Have you considered batching the payments?  

---

## 1 answers

### Answer by username_2 on 2020-02-18. Score: 2 | Accepted answer

A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:

**Start with more UTXOs.** Each UTXO can be used to create <25 unconfirmed child transactions. So if you need to make `n` payments, you'll need at least `n/25` UTXOs to do so using this method.

However, you can definitely do this in a more cost-effective manner. As username_1 mentioned, **batch payments** describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction.

Another option is to use the **lightning network** to send your payments. Lightning transactions are *extremely* cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.

> **Comments:**
> **username_0**: Thanks for the answer! I was not aware of the possibility of batching transactions. This sounds like what I’m looking for. Is there a disadvantage to batching many transactions (say 100) together? About the lightning network - wouldn’t that require the recipients of the payments to also be on the lightning network?  

---

