"minimum fee .1" on bitcoin core 15.0

[protonewb]

I have a weird issue - when combining many small inputs i'm getting an error message "this transaction requires a minimum fee of at least .1 BTC" - even though I have properly set the fee via settxnfee to a very low sat/byte rate (I'm in no rush). It seems to be forcing a much higher fee rate.

There is nothing fee-specific in the config file, and I can see the proper fee set when i run "getwalletinfo" - where is this "minimum fee" coming from and how do I get around it? - thanks.

Even worse is - if there are additional funds to pay the flat .1 btc rate, it will send the txn with .1 fee overriding my much lower specified fee, with no warning.

[1713883564]

1713883564

[1713883564]

1713883564

[1713883564]

1713883564

[1713883564]

1713883564

[1713883564]

1713883564

[LoyceV]

How big is the transaction you're trying to make (in bytes)?

I suggest to Enable coin control features (under Options > Wallet), select your own inputs, and create several smaller transactions. Take for example 10 inputs per transaction, set a low fee, and send it to one of your own addresses.

If your inputs are too low, say 10,000 satoshi or less, it's mose likely not worth the fee anymore.

[protonewb]

Thanks for the response - Yes, it's large in bytes. Probably well over 100 inputs. And yes it works fine sending smaller chunks at a time with the fee I specified. But I'd like to know where the "cutoff" is and how this "minimum .1 BTC fee" works, especially as it can override your own set fee without warning.

I'm using command line so coin control is a bit harder.

Cheers.

[mocacinno]

How big is the transaction you're trying to make (in bytes)?

I suggest to Enable coin control features (under Options > Wallet), select your own inputs, and create several smaller transactions. Take for example 10 inputs per transaction, set a low fee, and send it to one of your own addresses.

If your inputs are too low, say 10,000 satoshi or less, it's mose likely not worth the fee anymore.

The sum of the fees of many small transactions will be bigger than the fees of one big transaction...

At this moment, the optimal fee for a 95% chance of getting into the next 3 blocks is 162 sat/byte
For example, a non-segwit wallet having 100 unspent outputs:

10 transactions spending 10 unspent outputs at a time:
tx size per tx =~ (10 x 147) + (1 x 34) + 10 + 10 = 1524
tx fee per tx = 1524 x 162 = 246888 satoshi's
tx fee for 10 transactions = 2.468.880 satoshi's

1 transaction spending all 100 unspent outputs at once:
tx size =~ (100 x 147) + (1 x 34) + 10 + 100 = 14844
tx fee for this transaction = 14844 x 162 = 2.404.880

So, in the end, you'd pay an extra 64.000 satoshi's, and you'd end up with 10 unspent outputs instead of one if you decide to split up the one big transaction into 10 smaller one's.

[IncomeCoin]

wooow 

how much you are trying to send that you want to pay 1000$ as fee for that 

[mocacinno]

Thanks for the response - Yes, it's large in bytes. Probably well over 100 inputs. And yes it works fine sending smaller chunks at a time with the fee I specified. But I'd like to know where the "cutoff" is and how this "minimum .1 BTC fee" works, especially as it can override your own set fee without warning.

I'm using command line so coin control is a bit harder.

Cheers.

There is a way around this problem, but since you're talking about 100+ unspent outputs, it'll require some scripting, either directly issuing calls to bitcoin-cli, or by using the json-rpc interface:
- listunspent
=> here you'll see the txid's and vout's... If you want to include unconfirmed unspent outputs (at your own risk), use "listunspent 0"
- getbalance
=> here you'll see the total sum of the amounts of the unspent outputs
- createrawtransaction
=> first,  calculate the size of the transactions, calculate the fee you want to pay and substract this fee from the amount you'll fund the receiving address with. Use the txid's and vout's of the first step
- signrawtransaction
=> AND manually review the transaction (decoderawtransaction)
- sendrawtransaction

If you follow this structure, you can pick your own fee... Hell, you can even make a 0 fee transaction . Do be carefull tough, cheaping out on the transaction fee might lead to an incomplete network propagation, and reasonable chance the transaction won't be included in any blocks before more and more nodes drop it from their mempool.

EDIT: it might be a good idear to check if you opted in for RBF (to be sure, start bitcoind with the -walletrbf parameter). This way you can always try to bump the fee if the waiting gets to you

[IncomeCoin]

The sum of the fees of many small transactions will be bigger than the fees of one big transaction...

At this moment, the optimal fee for a 95% chance of getting into the next 3 blocks is 162 sat/byte
For example, a non-segwit wallet having 100 unspent outputs:

10 transactions spending 10 unspent outputs at a time:
tx size per tx =~ (10 x 147) + (1 x 34) + 10 + 10 = 1524
tx fee per tx = 1524 x 162 = 246888 satoshi's
tx fee for 10 transactions = 2.468.880 satoshi's

1 transaction spending all 100 unspent outputs at once:
tx size =~ (100 x 147) + (1 x 34) + 10 + 100 = 14844
tx fee for this transaction = 14844 x 162 = 2.404.880

So, in the end, you'd pay an extra 64.000 satoshi's, and you'd end up with 10 unspent outputs instead of one if you decide to split up the one big transaction into 10 smaller one's.

thats why high ranked members are called Legendary, its a complete description for transaction fee calculator, i will make a page for calculating  in his/her name

[LoyceV]

The sum of the fees of many small transactions will be bigger than the fees of one big transaction...

True, but he won't hit the unexplained 0.1BTC fee. And I the feeling it's better to send 10 low-fee transactions of 2 kb each, than 1 low-fee transaction that takes 20 kb.

At this moment, the optimal fee for a 95% chance of getting into the next 3 blocks is 162 sat/byte

In protonewb's case, I'd send it with 11 sat/byte (he's in no rush). There's no need to be in the next 3 blocks. btc.com shows how the required fee drops hard after a block has been found, and then slowly goes up again. If 2 blocks are found close together, the second block gets filled with low-fee transactions. That's the sweetspot I aim for when I pay a low fee.

So, in the end, you'd pay an extra 64.000 satoshi's, and you'd end up with 10 unspent outputs instead of one if you decide to split up the one big transaction into 10 smaller one's.

For that reason, I take care of small change during my normal transactions. I don't let it collect until I have hundreds of them.
Then, when I really need to make a time-sensitive transfer, I pay a high fee for 1 input, instead of 10-100 inputs.

I'm using command line so coin control is a bit harder.

Any chance you can just download the wallet and do it from your local GUI?

[protonewb]

I obviously don't want to pay the $1000 fee. And yes, I understand the smaller transactions will cost a bit more. That's why I'd like to understand how this "Minimum .1 BTC fee" works. What is the cutoff, how can it be changed/worked around.

And I was hoping to do it without rawtransactions, which I am familiar with but don't feel comfortable using.

Can someone explain the ".1 BTC Minimum fee" and the exact mechanics - surely it's in the code somewhere. And yes I'd call it a bug that it overrides user set fee without warning from the normal command line send.

Thanks for the responses.

[mocacinno]

I obviously don't want to pay the $1000 fee. And yes, I understand the smaller transactions will cost a bit more. That's why I'd like to understand how this "Minimum .1 BTC fee" works. What is the cutoff, how can it be changed/worked around.

And I was hoping to do it without rawtransactions, which I am familiar with but don't feel comfortable using.

Can someone explain the ".1 BTC Minimum fee" and the exact mechanics - surely it's in the code somewhere. And yes I'd call it a bug that it overrides user set fee without warning from the normal command line send.

Thanks for the responses.

Just a remark: "settxnfee" does not exist, it's "settxfee"... If you have the first parameter in your config (or as a startup parameter), it'll probably get ignored (which might explain the behaviour you're noticing).You do have to realise that the fee is always given in sat/Kb, so if you have a lot of unspent outputs, the fee might still rise to +0,1 BTC

An interesting part of the bitcoin wiki:

Sending

Users can decide to pay a predefined fee rate by setting `-paytxfee=<n>` (or `settxfee <n>` rpc during runtime). A value of `n=0` signals Bitcoin Core to use floating fees. By default, Bitcoin Core will use floating fees.

Based on past transaction data, floating fees approximate the fees required to get into the `m`th block from now. This is configurable with `-txconfirmtarget=<m>` (default: `2`).

Sometimes, it is not possible to give good estimates, or an estimate at all. Therefore, a fallback value can be set with `-fallbackfee=<f>` (default: `0.0002` BTC/kB).

At all times, Bitcoin Core will cap fees at `-maxtxfee=<x>` (default: 0.10) BTC. Furthermore, Bitcoin Core will never create transactions smaller than the current minimum relay fee. Finally, a user can set the minimum fee rate for all transactions with `-mintxfee=<i>`, which defaults to 1000 satoshis per kB.


Note that a typical transaction is 500 bytes.

source: https://en.bitcoin.it/wiki/Transaction_fees


And from https://en.bitcoin.it/wiki/Running_Bitcoin

-paytxfee=<amt>    Fee (in BTC/kB) to add to transactions you send (default: 0.00)

[protonewb]

Yes, that was a typo , I use 'settxfee' and verify it is set via "getwalletinfo" which shows the proper rate.  And it works perfectly for smaller (size) transactions (they use my set fee no problem). I don't use any command line arguments, I don't believe I need to.

Thanks for the wiki info, I've seen it. Was hoping to reach someone who knows the code to see what it's actually doing in this case, and hopefully save people from the same fate in future releases by at least giving a warning should the .1 BTC fee be set overriding their existing setting.