1

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.

Improve this question
7
  • 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
    Jan 21 '20 at 9:16
  • 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
    Jan 21 '20 at 9:24
  • 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
    Jan 21 '20 at 9:38
  • 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
    Jan 21 '20 at 9:46
  • 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).
    – Ugam Kamat
    Jan 21 '20 at 9:59
1

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.

Improve this answer
4
  • 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
    Jan 30 '20 at 9:43
  • 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
    Jan 31 '20 at 17:53
  • What do you mean 100kb is the max. transaction size? Please share some resources to back that statement. @karimkorun
    – Gagandeep Singh
    Feb 1 '20 at 1:45
  • It's from the source code. github.com/bitcoin/bitcoin/blob/… 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
    Feb 2 '20 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.