Topic: Small UTXOs - page 2. (Read 352 times)

Yes, but not by much.

What you are describing is a child pays for parent (CPFP) transaction. By paying higher fee for a second transaction spending the unconfirmed output of the first transaction, you can use it to effectively bump the fee of the first transaction, meaning both transactions will be included in a block together. However, you need to take in to account the respective sizes of the transactions.

Your first transaction with 40 inputs and 1 output will be somewhere in the range of 4,000-6,000 vbytes (depending on legacy or segwit and assuming no multi-sig or other large scripts). Let's call it 5,000 vbytes for ease of the calculations. If you pay 35,000 sats for this, then you will be paying 7 sats/vbyte.

Your second transaction with 1 input and 1 output will be somewhere in the range of 200 vbytes. If you pay 107 sats/vbyte for this, then you will pay a total of 21,400 sats.

If you combine both your transactions, then you are looking at a size of 5,200 vbytes, paying a total fee of 56,400 sats, which works out at a combined effective fee rate of 10.8 sats/vbyte.

So although your second transaction would indeed boost the fee of the first one, it will only boost it by a small amount (from 7 to 10.8 sats/vbtye) since the first transaction is so much larger than the second. If you wanted to boost the first transaction significant, you would have to pay a very high fee for the second transaction. Alternatively, if you aren't in a hurry, wait until the mempool empties and then consolidate at 1 sat/vbyte.

I'd go much lower than 35k sat if you don't mind waiting for weeks or more.

Thanks for the responses.
I use bitcoin core to select the inputs, basically the bitcoin-cli.
Let's say, I will pay a very small fee of 35,000 sats to a 40 input / 1 output transaction. This will stay unconfirmed for a longer period (maybe 1-2-3 weeks). If it stays unconfirmed, I will try to spend the unconfirmed output into another output, this time with the highest fee of a 1 input / 1 output transaction (at the time of writing this post at a 107 sats / vbyte, a total of about 15,000 sats). Will this increase my chances of being both transactions included into a block?

No. An input is roughly 68vbytes and 10 inputs would be only 680vbytes (0.68vKB). The limit for the transaction to be considered standard is 400,000 weight units or 100,000vBytes. What he meant was that splitting your (presumably large) consolidation into multiple of them would give the transaction a better chance to be fit into a block. Ie, Having a 10KB transaction when the miner can only fit 9KB left, the miner could possibly choose to include other transaction so the space is optimized.

I don't think there is any harm to have a larger transaction as long as it's under 100vKB and you have flagged it as opt-in RBF so it's easily replaceable if needed.

No, 40 inputs will still be less than 10 kB.

Thanks, will check it out. So, what you suggest is that if I have 40 small inputs that I would like to consolidate, it is better to make 4 transaction each with 10 inputs and 1 output?

I'd use Coin Control to select the inputs you want, and send the entire amount with the lowest possible fee. Then make sure your wallet keeps broadcasting the transaction. See my topic on consolidating small inputs.

Just in case, I'd keep the transaction under 10 kB. It might be easier to fit a block that way.

What is the best way to group tens / hundreds of smaller inputs into a bigger output if speed of transaction is not important?
Just simply sign a transaction with a lower fee and eventually wait for the network to pick the transaction up?