This is an attempt at fixing #11134.
It basically adds the output type flag as is, which is then used to generate the change destination.
442@@ -443,9 +443,9 @@ UniValue sendtoaddress(const JSONRPCRequest& request)
443 return NullUniValue;
444 }
445
446- if (request.fHelp || request.params.size() < 2 || request.params.size() > 8)
447+ if (request.fHelp || request.params.size() < 2 || request.params.size() > 9)
448 throw std::runtime_error(
449- "sendtoaddress \"address\" amount ( \"comment\" \"comment_to\" subtractfeefromamount replaceable conf_target \"estimate_mode\")\n"
450+ "sendtoaddress \"address\" amount ( \"comment\" \"comment_to\" subtractfeefromamount replaceable conf_target \"estimate_mode\" \"style\" )\n"
change_style
?
GetArg("-changestyle")
?
522+ // Generate a new key that is added to wallet
523+ CPubKey newKey;
524+ if (!pwallet->GetKeyFromPool(newKey)) {
525+ throw JSONRPCError(RPC_WALLET_KEYPOOL_RAN_OUT, "Error: Keypool ran out, please call keypoolrefill first");
526+ }
527+ coin_control.destChange = pwallet->GetDestinationForKey(newKey, style);
m_change_style
to coin control so that a new key is consumed only when necessary. It can also helps in other send/fund calls. This should be used in:
https://github.com/bitcoin/bitcoin/blob/f74459dba6de4d4462860318f6ee5bda8522e07b/src/wallet/wallet.cpp#L2679
463@@ -464,6 +464,7 @@ UniValue sendtoaddress(const JSONRPCRequest& request)
464 " \"UNSET\"\n"
465 " \"ECONOMICAL\"\n"
466 " \"CONSERVATIVE\"\n"
467+ "9. \"style\" (string, optional, default='p2pkh') The address style to use for the change output. Valid options are 'p2pkh', 'p2sh_p2wpkh', and 'p2wpkh'"
'
with \"
. See:
https://github.com/bitcoin/bitcoin/blob/f74459dba6de4d4462860318f6ee5bda8522e07b/src/wallet/rpcdump.cpp#L87
Closing this as I’m not sure of a good way to stay up to date with the other PR. Will reopen once merged instead.
Edit: Reopened post-merge of dependent PR.
Tend to NACK here. If you really want to control the change type on a per-call basis, maybe you should use createrawtransaction. It is not our goal to support every edge use-case. I doubt the option in sendtoaddress will still be useful two releases in the future and we’d have to deprecate it with way too much effort.
Other than that, you could set the change type on the command line or use a more intelligent solution such as #12119 (not yet merged).
sendtoaddress
is a simple send command where you don’t even have control over how much fee you have to pay (single shot) and I don’t think we should add more “expert” functions there.
sendtoaddress
is createrawtransaction
which is way overkill 99% of the time. This desire to keep sendtoaddress
dumb to “not confuse users” is itself confusing to me. See also #11413 which invalidates the argument about fees above (unless it’s NAK’d and not merged).
kallewoof
promag
MarcoFalke
jonasschnelli
Labels
Wallet