how to combine multiple inputs into a single transaction

Hey folks I've got a bit of a challenge with my app, and since I'm just getting started in the world of BTC development, I could really use your insights. Here’s the deal: I have an API for a payment system built with Nest.js, and it’s linked to a bcoin node implementation. The node has a master wallet, with several accounts tied to it, dividing the wallet's balance among those accounts. The main issue arises when I need to send a larger amount of BTC; the number of inputs can skyrocket to around 400-500, which drives up the transaction fees. So, how can I lower the fees for these transactions? I've looked into some options and found that creating PSBTs from my accounts, finalizing all the inputs, and then broadcasting a single transaction with one input instead of hundreds might help. It sounds like a payjoin or coinjoin approach. But here’s the kicker: bcoin doesn’t support the PSBT BIP174 standard, and it seems like the whole thing is not getting much maintenance anymore. That bummed me out. I heard from someone over at bitcoinjs-lib that I could use their library to handle PSBTs while using bcoin to access the accounts, but it looks like no one has really combined these methods before. Has anyone tried working with bcoin in this way? What are some ways to tackle this issue? I’m open to other solutions or any help you can offer. Appreciate it! UPD: Some folks suggested checking out this CLI, but I'm a bit hesitant since it seems to rely on PSBTs as well. How would that work with my node? And if it's a viable option, how would I implement it?

I know nothing about "Bcoin", but I know a thing or two about consolidating small inputs. You should read that topic. One way or another, having 400 inputs will create a large transaction. If you can get away with 1.1 sat/vbyte, it's not that bad, so you'll have to time your transaction a bit.

1.1 sat/vbyte in these network conditions basically means your transaction will be kicked out of most nodes mempools' off and on, and won't confirm for several days. It's not exactly something I can recommend. Then again, neither is including 400 inputs, so I strongly suggest to OP to find a way to optimize the service to make smaller input transactions. Experimenting with this on testnet first might help.

All I can see is transactions <2 sat/vbyte are getting confirmed. If it gets dropped, raise the fee a bit. If it doesn't get dropped and doesn't confirm, use CPFP. Or just go for 2.1 sat/vbyte now, it's still less than 1 mBTC for 400 inputs.

Thank you for your help. I think I need to test both, decreasing comission rate and destructuring one big tx into several smaller.

I do not know if this is pertaining to Electrum or SPV wallets, but the size of the transaction must not be more than 100 kilobytes or its corresponding vsizes in nested or native segwit. This is the reason it is good to use a wallet that supports RBF, because with it you can pump the fee, instead of spending more fee on CPFP. Edit: 400 inputs can be in one transaction. The size is not up to 100000 while the vsizes will be smaller, 27244 vbytes for native segwit.

That's correct for small transactions. However, for transactions with many inputs, the minimum increase to use RBF will be much more than it costs to slightly increase the fee by using CPFP.

This basically consolidates all your UTXO in the change (and the sent amount). The only way to decrease the absolute fee for such huge transaction size is to lower the "fee rate" itself. If you wish to consolidate those inputs first then send that "bit large amount of BTC" using its output just right now, it'll just be a waste since you'll just separate the above in two separate transactions that are bundled (parent and child). The child transaction (uses the consolidation txn's output), is still subjected to the unconfirmed parent's size and fee. Consolidation should be done if it's possible to send a transaction with relatively low fee rate that can be mined, then it'll save you some fee when the average fee rate is high. I don't think "payjoin" or "coinjoin" could be a solution since those aren't workaround that will enable you to spend all of those 400-500UTXO as a single input without consolidating first. You still need to consolidate those small inputs via transaction which pays its own transaction fee.

I checked bcoin docs and found out there's parameter maxFee for API call POST /wallet/:id/send[1]? Have you tried using that? Bcoin basically is JS Bitcoin library with full node feature. In past, i reviewed it's full node feature. [1] https://bcoin.io/api-docs/#send-a-transaction

Thank to all of the speakers, the information provided helped me to unrstand the way I should work, optimizing commission rate rather then consolidating inputs.

Consolidating is still recommended when the time is right, when it's certain that it'll get confirmed even with a very low fee rate. So that if you ever need to spend while the average fee rate is too high, you wouldn't have to use hundreds of inputs but the single consolidated "confirmed" UTXO. Consolidating right when you need to send is the problem, since spending its "unconfirmed" unspent transaction output will just bundle the child transaction with it like I explained in the previous post.

Thank you to all of repliers. The advices helped me to implement the solution: 1. Using actual rates with this API https://api.blockcypher.com/v1/btc/main 2. Using RBF to increase comission rate of "old" txes