Small UTXOs

[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/.

[1715092520]

1715092520

[1715092520]

1715092520

[1715092520]

1715092520

[1715092520]

1715092520

[1715092520]

1715092520

[1715092520]

1715092520

[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.