Rebase #4331
- Resolve conflicts w/ moved src/core.h
- Resolve conflict in CoinControlDialog::updateLabels function
- Port the RPC test to python
544 | @@ -544,6 +545,11 @@ void CoinControlDialog::updateLabels(WalletModel *model, QDialog* dialog) 545 | // Fee 546 | nPayFee = CWallet::GetMinimumFee(nBytes, nTxConfirmTarget, mempool); 547 | 548 | + // in the subtract fee from amount case, we can tell if zero change already and subtract the bytes, so that fee calculation afterwards is accurate
this code-block needs to be moved one line above as the variable nBytes is used there
Thanks, good catch
nit: the second passage of the commit-message is now wrong, this was only true for the initial version of this pull-request, I'd say remove it, to avoid someone gets confused by it.
With regard to future extensibility, I like the idea of adding a JSON structure to sendmany. Should have been done that in the first place instead of the long-winded positional command lines for some methods.
803 | @@ -793,9 +804,9 @@ Value movecmd(const Array& params, bool fHelp) 804 | 805 | Value sendfrom(const Array& params, bool fHelp) 806 | { 807 | - if (fHelp || params.size() < 3 || params.size() > 6) 808 | + if (fHelp || params.size() < 3 || params.size() > 7) 809 | throw runtime_error( 810 | - "sendfrom \"fromaccount\" \"tobitcoinaddress\" amount ( minconf \"comment\" \"comment-to\" )\n" 811 | + "sendfrom \"fromaccount\" \"tobitcoinaddress\" amount ( minconf \"comment\" \"comment-to\" subtractfeefromamount )\n"
Do we really want to extend deprecated methods?
Agreed. JSON structures as parameter (or as optional parameter) would be more convenient and extendable. sandmany and sendfrom are also marked for deprecation so i assume main focus should be GUI and sendtoaddress.
eh, who is deprecating sendmany? If we were to keep one send* method, that would be the one. It is the most general send method.
@laanwj The JSON structure in the current PR only allows for a boolean for each recipient. Are you suggesting it be changed to a parameter object (eg, like getblocktemplate)? If so, I agree that seems like a better approach.
As far as multiple recipients sharing the fee, it seems more logical to be using an Array than an Object with only values of "true".
Re-ACK (including @luke-jr commits)
help-description of sendmany is now wrong after switching from object to array
Fixes #2724 and #1570.
Adds the
automatically-subtract-the-fee-from-the-amount-and-send-whats-left
feature to the GUI and RPC (sendtoaddress,sendmany).
Retested ACK. Binaries: https://builds.jonasschnelli.ch/pulls/5831/

Thanks for testing @jonasschnelli