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