<p>This is a common issue for any service with BTC incomings/outgoings. </p>

<p>The answer is simply to consolidate all your inputs in a large transaction all at once, so you remove possibly hundreds of small outputs, and get one big at the end. </p>

<p>Usually people do this semi-regularly, though you also see people waiting until mempool fees are super low.</p>

<p>One reason you can afford to pay a relatively low fee for consolidation transactions, is because you're planning ahead in your consolidation transactions. You don't need it confirmed immediately (like you would for outgoings, perhaps), so it's OK if it takes a few hours, once your wallet has enough to keep paying customers. </p>

<p>Just pick a moment when the mempool looks super empty, and it'll work really well. If it's not super empty, you can still try low-balling the fee and waiting longer.</p>

CC BY-SA 4.0
2020-01-30T09:43:11.297Z
Yes, that is what I have been thinking to do. But this approach only works when someone is receiving tons of small payments and then at the end of the day, they can transfer all the funds to a single address with the lowest possible fee, which is 1 sat/byte.  For segwit, each additional input adds 93 bytes to the transaction. So, a transaction with 1000 inputs(1000 small received payments) and 2 outputs by default is 93328 bytes, 0.00093328 BTC fees.
Gagandeep Singh
CC BY-SA 4.0
2020-01-31T17:53:15.310Z
1000 inputs is a lot - maybe you know that 100kb is literally a maximum transaction size on the network? Anyway, it's not the bitcoin networks fault your users are sending tiny tiny amounts. Fees are a reality, and some uses aren't meant to be. You should look into LN, otherwise you could go out of business if fees rise high enough :P (because future fees paid has nothing to do with coins you receive today)
karimkorun
CC BY-SA 4.0
2020-02-01T01:45:04.190Z
What do you mean 100kb is the max. transaction size? Please share some resources to back that statement. @karimkorun
Gagandeep Singh
CC BY-SA 4.0
2020-02-02T17:22:47.303Z
It's from the source code. https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.h#L24
MAX_STANDARD_TRANSACTION_WEIGHT / 4 = 100kb
This is 'policy', so it's not a consensus rule, but it IS still enforced by 99% of nodes. You won't be able to send >100kb txs unless you talk to a miner and get them to mine it.
karimkorun
CC BY-SA 4.0
2020-01-22T15:48:05.390Z
2020-01-22T15:48:05.390Z
karimkorun
<p>We have a bitcoin node running on a server which we use to generate addresses to receive small payments from the users. We receive tons of small payments daily right now and then we are using the same bitcoin wallet to send payouts to our users using the sendmany rpc call.</p>

<p>This results in lots of inputs to cover the amount in outputs. Each new input increases the size of transaction by around 150 bytes and so we are loosing too much in fee.</p>

<p>Is there any way to reduce the number of inputs?</p>

<p>Suggestions would be really appreciated.</p>

<p>Thank you.</p>

CC BY-SA 4.0
2020-01-21T09:16:16.257Z
If you are accepting high volume of small transactions, you will be better off accepting bitcoins using Lightning Network. You could use open source solutions like BTCPayServer (not an endorsement, verify yourself) for generating lightning invoices which can be deployed as a self hosted solution or on a third party server.
Ugam Kamat
CC BY-SA 4.0
2020-01-21T09:24:48.000Z
But I am looking for a solution without using LN. Because I need a solution not only for BTC but for other similar ones like LTC, DOGE, etc. which doesn't have LN support yet.
Gagandeep Singh
CC BY-SA 4.0
2020-01-21T09:38:25.637Z
I don't see a way out of it. Bitcoin operates on a UTXO based model rather than an account based model. So you WILL have to consolidate the UTXOs at one point or another. The only thing that I can think off to alleviate the problem is by using some optimizations of inputs to match the payouts that you guys do.
Ugam Kamat
CC BY-SA 4.0
2020-01-21T09:46:07.753Z
What if I make an internal transfer to an address on the same wallet with a very low fee? This will move all the unspent outputs to one single output which can be used later to pay other addresses. This is beneficial only if I can set a fee something below 1 sat/byte? Can I?
Gagandeep Singh
CC BY-SA 4.0
2020-01-21T09:59:17.670Z
No, you cannot set fee below 1sat/vbyte. Currently Bitcoin Core uses a `minRelayTxFee` of 1sat/vbyte. If you create a transaction below that fee rate then it will be treated as non-standard and the nodes won't relay your transaction forward. Even if you do an internal transfer, you will have to pay fee on the inputs that you add to the transaction. The best cost beneficial way you have if to prevent change outputs by optimizing the inputs (care has to be taken to preserve privacy though).
Ugam Kamat
CC BY-SA 4.0
2020-01-21T13:54:58.143Z
Theoretically it could be done but practically it may not be possible. In theory, you could use `SigHash_All | SigHash_AnyoneCanPay` and set one output with a certain amount and reveal the tx. Now each user can add his own input with `AnyoneCanPay` and any amount. The tx won't be mineable until total input value exceeds that amount.
Coding Enthusiast
CC BY-SA 4.0
2020-01-21T18:56:55.477Z
@CodingEnthusiast you would open yourself up for double spend attacks with that logic. People will sign the anyonecanpay input, leave the shop and spend the same input someplace else. Now that particular input is invalid.
Ugam Kamat
<bitcoin-core><bitcoind><bitcoin-cli>
How to reduce number of inputs in bitcoin transaction?
Gagandeep Singh
# How to reduce number of inputs in bitcoin transaction?

(Asked by: username_0 on 2020-01-21)

We have a bitcoin node running on a server which we use to generate addresses to receive small payments from the users. We receive tons of small payments daily right now and then we are using the same bitcoin wallet to send payouts to our users using the sendmany rpc call.

This results in lots of inputs to cover the amount in outputs. Each new input increases the size of transaction by around 150 bytes and so we are loosing too much in fee.

Is there any way to reduce the number of inputs?

Suggestions would be really appreciated.

Thank you.

**Tags:** bitcoin-core, bitcoind, bitcoin-cli

> **Comments:**
> **username_1**: If you are accepting high volume of small transactions, you will be better off accepting bitcoins using Lightning Network. You could use open source solutions like BTCPayServer (not an endorsement, verify yourself) for generating lightning invoices which can be deployed as a self hosted solution or on a third party server.  
> **username_0**: But I am looking for a solution without using LN. Because I need a solution not only for BTC but for other similar ones like LTC, DOGE, etc. which doesn't have LN support yet.  
> **username_1**: I don't see a way out of it. Bitcoin operates on a UTXO based model rather than an account based model. So you WILL have to consolidate the UTXOs at one point or another. The only thing that I can think off to alleviate the problem is by using some optimizations of inputs to match the payouts that you guys do.  
> **username_0**: What if I make an internal transfer to an address on the same wallet with a very low fee? This will move all the unspent outputs to one single output which can be used later to pay other addresses. This is beneficial only if I can set a fee something below 1 sat/byte? Can I?  
> **username_1**: No, you cannot set fee below 1sat/vbyte. Currently Bitcoin Core uses a `minRelayTxFee` of 1sat/vbyte. If you create a transaction below that fee rate then it will be treated as non-standard and the nodes won't relay your transaction forward. Even if you do an internal transfer, you will have to pay fee on the inputs that you add to the transaction. The best cost beneficial way you have if to prevent change outputs by optimizing the inputs (care has to be taken to preserve privacy though).  
> **username_2**: Theoretically it could be done but practically it may not be possible. In theory, you could use `SigHash_All | SigHash_AnyoneCanPay` and set one output with a certain amount and reveal the tx. Now each user can add his own input with `AnyoneCanPay` and any amount. The tx won't be mineable until total input value exceeds that amount.  
> **username_1**: @username_2 you would open yourself up for double spend attacks with that logic. People will sign the anyonecanpay input, leave the shop and spend the same input someplace else. Now that particular input is invalid.  

---

## 1 answers

### Answer by username_3 on 2020-01-22. Score: 2

This is a common issue for any service with BTC incomings/outgoings.

The answer is simply to consolidate all your inputs in a large transaction all at once, so you remove possibly hundreds of small outputs, and get one big at the end.

Usually people do this semi-regularly, though you also see people waiting until mempool fees are super low.

One reason you can afford to pay a relatively low fee for consolidation transactions, is because you're planning ahead in your consolidation transactions. You don't need it confirmed immediately (like you would for outgoings, perhaps), so it's OK if it takes a few hours, once your wallet has enough to keep paying customers.

Just pick a moment when the mempool looks super empty, and it'll work really well. If it's not super empty, you can still try low-balling the fee and waiting longer.

> **Comments:**
> **username_0**: Yes, that is what I have been thinking to do. But this approach only works when someone is receiving tons of small payments and then at the end of the day, they can transfer all the funds to a single address with the lowest possible fee, which is 1 sat/byte.  For segwit, each additional input adds 93 bytes to the transaction. So, a transaction with 1000 inputs(1000 small received payments) and 2 outputs by default is 93328 bytes, 0.00093328 BTC fees.  
> **username_3**: 1000 inputs is a lot - maybe you know that 100kb is literally a maximum transaction size on the network? Anyway, it's not the bitcoin networks fault your users are sending tiny tiny amounts. Fees are a reality, and some uses aren't meant to be. You should look into LN, otherwise you could go out of business if fees rise high enough :P (because future fees paid has nothing to do with coins you receive today)  
> **username_0**: What do you mean 100kb is the max. transaction size? Please share some resources to back that statement. @username_3  
> **username_3**: It's from the source code. https://github.com/bitcoin/bitcoin/blob/99813a9745fe10a58bedd7a4cb721faf14f907a4/src/policy/policy.h#L24 MAX_STANDARD_TRANSACTION_WEIGHT / 4 = 100kb This is 'policy', so it's not a consensus rule, but it IS still enforced by 99% of nodes. You won't be able to send >100kb txs unless you talk to a miner and get them to mine it.  

---

