Recent discussion (in IRC meetings, and e.g. #8989) has shown a preference for the default confirm target for smartfees to be 6 instead of 2, to avoid overpaying fees for questionable gain.
6 is also a compromise between the GUI’s pre-#8989 value of 25 and the bitcoind -txconfirmtarget default of 2. These were unified in #8989, but this has made the (overly expensive) default of 2 as GUI default.
(needs mention in 0.14 release notes)
Recent discussion (in IRC meetings, and e.g. #8989) has shown a
preference for the default confirm target for smartfees to be 6 instead
of 2, to avoid overpaying fees for questionable gain.
6 is also a compromise between the GUI's pre-#8989 value of 25 and the
bitcoind `-txconfirmtarget` default of 2. These were unified in #8989,
but this has made the (overly expensive) default of 2 as GUI default.
utACK 0fdf810d267928b4c26a2e2cbb8c02b79e7b0ccb.
We should think about adding a confirmation-target to fundrawtx, though we could argue that the custom feerate-option (recently added) in conjunction with estimatesmartfee should be sufficient.
Also, AFAIK, there is no runtime option to change the default confirmation target requiring users using sendto*** RPC calls to restart bitcoind in order to change the confirmation target.
Also, AFAIK, there is no runtime option to change the default confirmation target requiring users using sendto*** RPC calls to restart bitcoind in order to change the confirmation target.
I’m not so happy about RPC calls changing (specific) global defaults. The way -paytxfee and payTxFee is handled has always bothered me. If we’re going to allow changing global configuration parameters there needs to be a generic solution for that. E.g. setoption RPC (there has been work in this direction).
However there needs to be a way to pass the confirmation target etc. to the RPC sending calls without changing the global default, this would extend the feature set to that of the GUI. E.g. a sendParameters object (which would set fields in the CoinControl structure internally).
I’m not so happy about RPC calls changing global defaults. The way -paytxfee and payTxFee is handled has always bothered me.
Yes. A runtime change is probably undesirable.
But a per-send custom confirmation target via sendto* could be possible. Though it would be probably the 7 parameter in row after subtractFeeFromAmount (reminds me that we should not forget about #8811).
But a per-send custom confirmation target via sendto* could be possible.
Yes, sendtoadress is a mess (indeed, #8811 with named arguments would help there). fundrawtransaction however already has a parameters object passed in, so this could just be added?
fundrawtransaction however already has a parameters object passed in, so this could just be added?
Yes. But somehow it’s already possible:
0x = estimatesmartfee(<conftarget>)
1fundrawtransaction <rawtx> '{"feeRate":x}
