Small UTXOs

[zoltanb]

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?

[1714167095]

1714167095

[1714167095]

1714167095

[LoyceV]

What is the best way to group tens / hundreds of smaller inputs into a bigger output if speed of transaction is not important?

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.

[zoltanb]

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.

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?

[LoyceMobile]

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

[ranochigo]

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?

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.

[zoltanb]

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?

[LoyceMobile]

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

[o_e_l_e_o]

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?

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.

[HCP]

Alternatively, if you aren't in a hurry, wait until the mempool empties and then consolidate at 1 sat/vbyte.

Could be waiting quite a long time for that to happen again... The mempool hasn't been close to empty for quite a while now

https://mempool.space/graphs#1m

I've been wanting to consolidate some stuff... and it's just not feasible with the current network state Even the traditionally "quiet" weekend periods have been busy. And you can't just fire off a 1 sat/vbyte transaction and hope for the best any more... with a flooded mempool, the current mempool min fee is like 2 sats/vbyte

[bitmover]

Alternatively, if you aren't in a hurry, wait until the mempool empties and then consolidate at 1 sat/vbyte.

Could be waiting quite a long time for that to happen again... The mempool hasn't been close to empty for quite a while now

https://mempool.space/graphs#1m

I don't think it will take that long. In the graphic you posted the mempool was nearly cleared at 30/01.



And there were other moments last week (07/02) when a 3 sat/byte would also get a confirmation as well.

Personally, I would just fire a 1 sat/byte transaction with all those 40 inputs and wait.
It is probably going to take at least 1 week to get a confirmation. By the end of the month he will very likely to have all inputs in a single UTXO for a very low fee...

Using this tool, 40 inputs and 1 output would have about  6000 to 2700 bytes (depending on address format) and a 1 sat/byte transaction would range from 0.00002794 to 0.00006  BTC to transact (depending on format, from 1.30 to 3.00 usd)

I would certainly make a 1sat/byte tx.

[o_e_l_e_o]

I don't think it will take that long. In the graphic you posted the mempool was nearly cleared at 30/01.

That big dip at 30/01 is a simple bug. Perhaps the node they are using for their data went offline for a few minutes, or purged its mempool for some reason and had to re-receive all the unconfirmed transactions. There is no way that 70 MB of transactions were processed that quickly and then replace with 70 MB of new ones.

HCP is right. The mempool hasn't been below 50 MB since January 7th, and as long as we continue this ridiculous bull run, it won't be for a long time yet I would think. There are probably also a few dozen more MB of low fee transactions which have been dropped in that time.

Still, I've got some consolidating to do, and I'm happy to wait until March or even April to get that sweet 1 sat/vbyte. I don't mind paying a higher fee when needed, but consolidation can always wait.

[bitmover]

HCP is right. The mempool hasn't been below 50 MB since January 7th, and as long as we continue this ridiculous bull run, it won't be for a long time yet I would think. There are probably also a few dozen more MB of low fee transactions which have been dropped in that time.

I made a 1 sat byte (1 sat/wu, 5 sat/vbyte)transaction 16 January from my signature campaign address.

https://www.blockchain.com/btc/tx/3f1c9ecba89229e7568f0a9ac01b632279ca880cec9c84a4b77b0ebaa293cf9d


we are having 1 sat/byte transaction confirmed every week...

A 50mb mempool doesn't mean you won't get a confirmation with a low fee

Now the mempool has about 70mb, but with 7 sat/byte you can get a confirmation.

In mempool.space the mempool is about 150mb, but I got only 70mb in mine. But it still shows up that it is possible to get a confirmation with 7 sat/byte

https://mempool.space/graphs#2h


I just went through the last block, i found some low fee confirmed transactions. All of them 7 sat/byte in block 670809 (just now):
https://blockchair.com/bitcoin/transaction/171e66023baa035bfa43ceee08e11a320b32a7ca6629a02b43d5a11b5bc40386
https://blockchair.com/bitcoin/transaction/3af106f1707d8d126e71ca7e4889858722b93229b5ceb8d7397881b217959165
https://blockchair.com/bitcoin/transaction/a8e8ba5b6c237c5c1bce234deddda1a20b7ffd778e158aaae73f278e21fd8089
https://blockchair.com/bitcoin/transaction/c2c1ae512405e24019d43992869f83b5669e14ec3a13d4054843656d84d874f0
https://blockchair.com/bitcoin/transaction/42597d91e8ee6b7e714a5d05395a85096d9dcb3e9cda7e6ad0cee2614fc8cd1e

So, to sum up: A big mempool doesn't mean a high fee if the size is getting smaller after each block.

Still, I've got some consolidating to do, and I'm happy to wait until March or even April to get that sweet 1 sat/vbyte.

You can do it now, it will very likely get confirmed within a few days. Don't worry.


edit:

We got 2336 1-2 sat/byte transactions confirmed in the last 12 days:
https://blockchair.com/bitcoin/transactions?q=block_id(669000..680000),fee_per_kb(1000..2000)&s=id(asc),fee_per_kb(desc)#

few examples:
https://blockchair.com/bitcoin/transaction/612702324
https://blockchair.com/bitcoin/transaction/612704639
https://blockchair.com/bitcoin/transaction/612706083

[o_e_l_e_o]

I made a 1 sat byte transaction 16 January from my signature campaign address.

That transaction is 1.27 sat/WU, which works out to over 5 sat/vbyte.

In mempool.space the mempool is about 150mb, but I got only 70mb in mine. But it still shows up that it is possible to get a confirmation with 7 sat/byte

Well yes, because the tip of the mempool is currently around 10 sat/vbyte, but there are still 130 MB of transactions below that.

We got 2336 1-2 sat/byte transactions confirmed in the last 12 days:

And there are currently over 20,000 transactions paying 1-2 sats/vbyte in the mempool, and several thousands more which will have been dropped over the last 12 days. Sure, a handful of low fee transactions will confirm because miners choose to include them (perhaps they have paid privately, or perhaps they have been boosted via CPFP, or perhaps they are the miners' own transactions, or that of their friends/associates, and so on), but most will sit unconfirmed until they are dropped from the mempool.

I prefer just to wait until the mempool is empty to do my consolidating.

[zoltanb]

Thanks for all the responses.
OK, all inputs are 3xxx (p2sh-segwit) and bc1xxx (bech32) and the output is a bech32 address.
How do I calculate the exact transaction size to set my fee accordingly?

[ranochigo]

Thanks for all the responses.
OK, all inputs are 3xxx (p2sh-segwit) and bc1xxx (bech32) and the output is a bech32 address.
How do I calculate the exact transaction size to set my fee accordingly?

Here: https://jlopp.github.io/bitcoin-transaction-size-calculator/

What wallet are you using? Most wallets should let you define your fee rates and give you the transaction size at the point of signing as well.

[LoyceV]

How do I calculate the exact transaction size to set my fee accordingly?

It shows on the Send tab under Coin Control Features.

[zoltanb]

I am using bitcoin core, bitcoin-cli but I am constructing the raw transaction manually.

[zoltanb]

Here: https://jlopp.github.io/bitcoin-transaction-size-calculator/

What wallet are you using? Most wallets should let you define your fee rates and give you the transaction size at the point of signing as well.

Used this one, I am just not sure about the type of transaction.
What if it is combined? 30 P2SH and 10 bech32 inputs, how do I enter it?

[pooya87]

Used this one, I am just not sure about the type of transaction.
What if it is combined? 30 P2SH and 10 bech32 inputs, how do I enter it?

If it is from a wallet that you have created then the input types should be the same since wallets don't usually generate more then one type of address. For example they are all P2WPKH addresses.
In any case there are other tools that you can use such as https://coinb.in/#fees but keep in mind that these are estimations, and can be wrong specially in case of multisig inputs since it depends on the number of pubkeys

[HCP]

Used this one, I am just not sure about the type of transaction.
What if it is combined? 30 P2SH and 10 bech32 inputs, how do I enter it?

If it is from a wallet that you have created then the input types should be the same since wallets don't usually generate more then one type of address.

OP is using Bitcoin Core... which will let you generate all three... Legacy, Nested and Native... (and create MultiSig's if you want )

I am using bitcoin core, bitcoin-cli but I am constructing the raw transaction manually.

So, it's entirely possible they have 30 P2SH and 10 bech32 inputs... Generally, it's caused by using the "default" options (which tries to generate bech32 addresses), but then unchecking the "generate native segwit (bech 32) address" box in the "receive" tab... this will give you a P2SH-P2WPKH (nested) receive address... but when you spend these coins, Bitcoin Core will default to bech32 change addresses if you haven't explicitly set it using the commandline arguments.

-addresstype
What type of addresses to use ("legacy", "p2sh-segwit", or "bech32", default: "bech32")

-changetype
What type of change to use ("legacy", "p2sh-segwit", or "bech32"). Default is same as -addresstype, except when -addresstype=p2sh-segwit a native segwit output is used when sending to a native segwit address)

[ranochigo]

I am using bitcoin core, bitcoin-cli but I am constructing the raw transaction manually.

If you want to do that, would it be better for you to create a raw transaction without any inputs and use fundrawtransaction to add the inputs instead? If you were to specify the fee rate as well as the deduction of the fees from the outputs, then it would be far easier than to calculate the fees manually. See this: https://bitcoincore.org/en/doc/0.18.0/rpc/rawtransactions/fundrawtransaction/.

[pooya87]

OP is using Bitcoin Core... which will let you generate all three... Legacy, Nested and Native... (and create MultiSig's if you want )

That's true but I assumed OP is only using core for signing not creating the wallet itself. I may have been wrong.
Usually all wallets including core let you choose your address type whether in the same wallet file or force creation of a new one but the user has to always explicitly request a new address type.

[zoltanb]

Used this one, I am just not sure about the type of transaction.
What if it is combined? 30 P2SH and 10 bech32 inputs, how do I enter it?

If it is from a wallet that you have created then the input types should be the same since wallets don't usually generate more then one type of address.

OP is using Bitcoin Core... which will let you generate all three... Legacy, Nested and Native... (and create MultiSig's if you want )

I am using bitcoin core, bitcoin-cli but I am constructing the raw transaction manually.

So, it's entirely possible they have 30 P2SH and 10 bech32 inputs... Generally, it's caused by using the "default" options (which tries to generate bech32 addresses), but then unchecking the "generate native segwit (bech 32) address" box in the "receive" tab... this will give you a P2SH-P2WPKH (nested) receive address... but when you spend these coins, Bitcoin Core will default to bech32 change addresses if you haven't explicitly set it using the commandline arguments.

-addresstype
What type of addresses to use ("legacy", "p2sh-segwit", or "bech32", default: "bech32")

-changetype
What type of change to use ("legacy", "p2sh-segwit", or "bech32"). Default is same as -addresstype, except when -addresstype=p2sh-segwit a native segwit output is used when sending to a native segwit address)

Exactly. You summarized it very well.

[HCP]

The days of 1 sat/byte transactions are gone for a while, I suspect...



and at one point it was purging transactions below 5 sats/vbyte: https://statoshi.info/d/000000020/memory-pool?orgId=1

Given the insane bull run we're on and breaking $50k... nodes are now purging transactions below 4 sats/vbyte due to "mempool min fee"... I can't even attempt to send a 3.6 sat/vbyte transaction:

mempool min fee not met, 707 < 806 (code -26)

[zoltanb]

Is there any way to bypass this error message?
error code: -26
error message:
mempool min fee not met, 15000 < 17463

[LoyceV]

Is there any way to bypass this error message?
error code: -26
error message:
mempool min fee not met, 15000 < 17463

I haven't experienced it yet, but I read (some) mempools increased the minimum fee.
If you copy the raw signed transaction, you can try broadcasting it through other sites:
https://blockchair.com/broadcast
https://coinb.in/#broadcast
https://www.blockchain.com/btc/pushtx

[HCP]

Also ensure the transaction fee rate at least 1 sat/vbyte, because AFAIK Bitcoin Core also shows same error if transaction fee rate at least 1 sat/vbyte.

It isn't a "min relay" error... it is "mempool min fee"... because of the huge size of the mempool... transactions that are extremely far away from the tip get purged (I believe the idea is that you no longer have to wait 14 days for the transaction to get "dropped" if there is literally 0% chance of your transaction getting confirmed within that timeframe and also to keep the mempool memory usage size under control).

The 2 places I know of that give an indication of what the "mempool min fee" likely to being currently used by default nodes are:
mempool.space:


Check the "purging" value... currently any transaction with less than a fee rate of 6.5 sats/vbyte will likely be removed from a (default configured) node to try and keep the mempool memory usage down at the 300MB range.


or, statoshi.info:


The bottom graph on the "Memory Pool" page shows the "mempool min fee" rate...

[o_e_l_e_o]

The 2 places I know of that give an indication of what the "mempool min fee" likely to being currently used by default nodes

You can also see this on Jochen's site by using the "BTC (default mempool)" option at the top, rather than the "BTC" option. It is quite nice to be able to compare the two and see just how much is being purged from default nodes. At the moment it is about 125 vMB of transactions.