rpc: Ignore sendmany::minconf as dummy value #15596

maflcko · 2019-03-13T22:26:04Z

Other RPCs such as sendtoaddress don't have this option at all and sendmany should by default spend from (lets say) our change.

promag · 2019-03-14T14:23:25Z

Should minconf be CoinEligibilityFilter::conf_theirs?

maflcko · 2019-03-14T14:37:38Z

That is not clear from the description in the rpc help. And I'd rather not change the behaviour of coinselection for this rpc, since that will change how it behaved previously. (See also #15595 (comment), where I tried to pass it down to coinselection)

practicalswift · 2019-03-14T19:52:01Z

GetLegacyBalance is unused and should be removed, no?
.
TBH this kind of stuff should really be identified automatically and fixed before human review takes place -- we really need to use better tooling in Travis :-)

-BEGIN VERIFY SCRIPT- sed -i --regexp-extended -e 's/const CWalletTx ?\* ?pcoin = &/const CWalletTx\& wtx = /g' src/wallet/wallet.cpp sed -i -e 's/\<pcoin->/wtx./g' src/wallet/wallet.cpp sed -i -e 's/\<pcoin\>/\&wtx/g' src/wallet/wallet.cpp -END VERIFY SCRIPT-

DrahtBot · 2019-03-14T22:14:57Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#15729 (rpc: Ignore minconf parameter in getbalance by promag)
#13756 (wallet: "avoid_reuse" wallet flag for improved privacy by kallewoof)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

maflcko · 2019-03-18T15:30:40Z

Removed all now unused methods

maflcko · 2019-03-18T19:52:15Z

@jnewbery

ryanofsky

utACK fac1a0f. This seems like a nice simplifying change, but I think it could definitely be documented better (better commit message and release notes).

ryanofsky · 2019-03-20T15:56:58Z

src/wallet/rpcwallet.cpp

@@ -929,11 +926,6 @@ static UniValue sendmany(const JSONRPCRequest& request)

    EnsureWalletIsUnlocked(pwallet);

-    // Check funds
-    if (totalAmount > pwallet->GetLegacyBalance(ISMINE_SPENDABLE, nMinDepth)) {


In commit "rpc: Document that minconf is an ignored dummy value" (fae5f87)

Is this commit description actually accurate? Is this just documenting existing behavior or changing the behavior?

If this commit is changing the behavior, I think there should be release notes saying min_depth is now ignored. Also, maybe this should raise an error if min_depth is passed and is set to anything other than 1.

If this commit isn't changing behavior, and min depth was ignored all along, the commit message should directly say it was already ignored, and maybe explain how setting a value didn't have any effect. Also, there could still be release notes saying that sendmany will now throw "Insufficient funds" (from CreateTransaction) instead of "Wallet has insufficient funds."

Strictly speaking it is changing behavior, since it might throw a different rpc error (or none at all and succeed) now. However, the previous behavior was not well specified by the documentation string of minconf. And my attempt at making sense of it failed:

rpc: Actually use sendmany::minconf rpc: Actually use sendmany::minconf #15595

By not throwing an error the client may think min_depth is still used and never update his code.

Also, maybe this should raise an error if min_depth is passed and is set to anything other than 1.

I think @ryanofsky suggestion should be considered.

That is just going to open a can of worms. I think, either it should throw for any value (including 1, the default), since that was ignored before as well, or never throw at all.

If it throws for all values, you might as well just remove the parameter and break the interface. Though, then that'd have to go through a -deprecatedrpc cycle. I don't think this effort is justified. Please explain why ignoring this parameter could lead to any meaningful issues

I think ignoring doesn't raise awareness and clients remain deluded, as we were.

I also understand the effort concern, but we do have a clear way to deprecate things and break backward compatibility, so why deal with this as a special case, and leave the parameter sitting there?

I can see both sides. In this case though, I think we should just silently ignore. I don't see any downside to clients continuing to specify this and having it ignored. The help text has been updated to "ignore dummy value", so I don't think there's any chance of users being confused by this.

Enforcing that this be set to 1 would give the impression that the passed value actually does something.

The help text is worthless for existing software.

This will be mentioned in the release notes and RPC help, if people don't read those when upgrading their bitcoind backend, I don't think there is much we can do. Making it an error to pass something other than 1 is not going them to read them either, but just modify their code to pass 1, what is the point then?

The help text is worthless for existing software.

For existing software, the only thing throwing an error would do is make the user change the client so it sets this to 1 or omit it. The end result will be the same as if the RPC doesn't throw an error, except there would be more disruption for users during transition.

If this PR were actually deprecating useful functionality, then I'd agree with you, but it's not. This option has never done what the help text implies that it should do.

maflcko · 2019-03-20T16:49:13Z

Added a writeup as requested by @ryanofsky

ryanofsky

utACK fabfb79. Nice writeup! Release notes are only change since previous review.

jnewbery · 2019-03-21T14:47:05Z

Concept ACK

promag · 2019-03-22T00:42:55Z

ACK behavior change, and no change in tests 😕

jnewbery · 2019-04-01T15:01:58Z

utACK fabfb79

The fact that this parameter was not covered by any test cases is indication that it was underspecified.

Nice incidental correction of coin -> wtx.

promag

NACK, I think ignoring is bad - clients should update to use a default value or omit. Discussion in #15596 (comment)

maflcko · 2019-04-03T16:07:09Z

I am going to merge this tomorrow unless there are further concerns

fabfb79 doc: Add release notes for 15596 (MarcoFalke) fac1a0f wallet: Remove unused GetLegacyBalance (MarcoFalke) faa3a24 scripted-diff: wallet: Rename pcoin to wtx (MarcoFalke) fae5f87 rpc: Document that minconf is an ignored dummy value (MarcoFalke) Pull request description: Other RPCs such as `sendtoaddress` don't have this option at all and `sendmany` should by default spend from (lets say) our change. ACKs for commit fabfb7: jnewbery: utACK fabfb79 ryanofsky: utACK fabfb79. Nice writeup! Release notes are only change since previous review. Tree-SHA512: 2526ead2330be7c2beb78b96bc5e55440566c4a3a809bbbd66f5c9fc517f6890affa5d14005dc102644d49679a374510f9507255e870cf88aaa63e429beef658

luke-jr · 2019-04-08T14:29:10Z

doc/release-notes.md

+
+* The `sendmany` RPC had an argument `minconf` that was not well specified and
+  would lead to RPC errors even when the wallet's coin selection would succeed.
+  The `sendtoaddress` RPC never had this check, so to normalize the behavior,


The reasoning here is flawed, BTW. sendtoaddress was kind of soft-deprecated by sendmany.

It is just one of many reasons why the arg should be ignored. Feel free to remove that reasoning, the others should still hold.

gmaxwell · 2019-11-24T18:07:21Z

Since some people reading the release notes are probably going to end up here confused (I did), I thought it would be useful to write my understanding here.

The min_conf argument to sendmany was functionally part of the now gone "accounts" system. ... that's also why it was only an argument to sendmany and not sendtoaddress, since sendmany had an account parameter (and as luke-noted, sendtoaddress was soft-deprecated).

The accounts system was intended to provide the backing logic for a shared user wallet (in particular, mybitcoin which went away after "losing" half its users funds). Especially after the mental model of UTXO and such started becoming understood by users, accounts functions were commonly misunderstood to be coincontrol features, but they never were: The wallet was written almost entirely with the view that the underlying output model would be hidden from the user. And for a shared-wallet it would be generally undesirable to have multiple users mean separate wallets because of the loss of fee efficiency, in any case.

The purpose of min_conf was accurately documented in the help: Use the balance according to a specified number of confirmations. This did not mean use the coins of a specific depth: remember accounts were not a coin-control feature, and the abstraction of coins was originally intended to be completely hidden from the users.

The reason an accounts-based shared wallet would want to use this is to prevent an attack where a user deposits some coins, waits for 1 conf (so their balance goes up) then withdraw that amount (which they can because their balance is high enough) which then ends up selecting some different >6 conf coins (since that is coinselection's extremely strong preference) ... then reorg the chain 1 block to claw their payment back while leaving the withdraw in place. ... leaving the user with a negative balance which they never repay. By setting min_conf to 6, a permitted payment would not result in the user's balance becoming negative if there was a 6 or fewer block reorg + doublespend.

Though I'm not sure of it, I would be surprised if this option wasn't added in direct response to actual losses.

Since the accounts system is gone, this setting doesn't have a real use anymore AFAICT. It probably would have been better if the release notes had said that, rather than suggesting some coin-controlly things which this setting never accomplished, not intended to accomplish, nor was documented to accomplish.

It's possible someone was using it to make sure they didn't overspend relative to their well confirmed coins and end up insolvent and owing people for payments in the event of a reorg beyond what they can make good for-- but I doubt it. If so, I believe there is currently no alternative functionality available for them (certainly not any of the options mentioned in the release notes).

Nor could the setting really have been re-purposed to some coin control-ish purpose, even though filtering your coins by depth is a pretty reasonable ask-- because change and third party payments really need to be treated distinctly if you do that kind of filtering because otherwise any filtering means you can't use your own change which is extremely disruptive and surprising, particularly since the interface mostly hides the fact that transacting temporarily kicks an essentially random amount of your balance to unconfirmed status. Any kind of min_conf coin control setting would probably need to work like the coin-selection does and have a separate argument for change (which would almost always be kept at the default of 0). ... maybe such a feature would even need three categories (immature coinbases) or four (change from segwit-only txn should probably be handled differently!). yuck: coin control is hard.

maflcko · 2019-11-24T18:44:10Z

Thanks for providing some more background on this. I read the release notes myself this morning and was confused by my own wording. Unfortunately it is now too late to change the release notes :(

jnewbery · 2019-11-24T22:08:58Z

What does soft-deprecated mean?

maflcko · 2019-11-24T22:40:51Z

What does soft-deprecated mean?

I think it means that there is an similar call that should be preferred, but the original one will never be removed.

gmaxwell · 2019-11-24T22:51:10Z

And, in particular, new functionality would be added to the new call... and the old call just hangs around for compatibility reasons, without changing except for bug fixes and trivial improvements.

Ref: bitcoin/bitcoin#15596

Summary: This is a partial backport of Core [[bitcoin/bitcoin#15596 | PR15596]] : bitcoin/bitcoin@fae5f87 Test Plan: ninja all check-all Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D6221

Summary: ``` -BEGIN VERIFY SCRIPT- sed -i --regexp-extended -e 's/const CWalletTx ?\* ?pcoin = &/const CWalletTx\& wtx = /g' src/wallet/wallet.cpp sed -i -e 's/\<pcoin->/wtx./g' src/wallet/wallet.cpp sed -i -e 's/\<pcoin\>/\&wtx/g' src/wallet/wallet.cpp -END VERIFY SCRIPT- ``` This is a partial backport of Core [[bitcoin/bitcoin#15596 | PR15596]] : bitcoin/bitcoin@faa3a24 Depends on D6221 Test Plan: ninja all check-all Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D6222

Summary: This is a partial backport of Core [[bitcoin/bitcoin#15596 | PR15596]] : bitcoin/bitcoin@fac1a0f Depends on D6222 Test Plan: ninja all check-all Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D6223

Summary: This is a partial backport of Core [[bitcoin/bitcoin#15596 | PR15596]] : bitcoin/bitcoin@fabfb79 Depends on D6223 Test Plan: Read. Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Subscribers: majcosta Differential Revision: https://reviews.bitcoinabc.org/D6224

rpc: Document that minconf is an ignored dummy value

fae5f87

maflcko mentioned this pull request Mar 13, 2019

rpc: Actually use sendmany::minconf #15595

Closed

maflcko added this to the 0.19.0 milestone Mar 13, 2019

maflcko added Wallet RPC/REST/ZMQ labels Mar 13, 2019

MarcoFalke added 2 commits March 14, 2019 16:03

wallet: Remove unused GetLegacyBalance

fac1a0f

maflcko force-pushed the 1903-rpcWalletDummySendmany_2 branch from ad4a5e0 to fac1a0f Compare March 14, 2019 20:05

ryanofsky approved these changes Mar 20, 2019

View reviewed changes

maflcko added Needs release note and removed Needs release note labels Mar 20, 2019

doc: Add release notes for 15596

fabfb79

ryanofsky approved these changes Mar 20, 2019

View reviewed changes

laanwj added this to Blockers in High-priority for review Mar 21, 2019

promag suggested changes Apr 2, 2019

View reviewed changes

promag mentioned this pull request Apr 3, 2019

rpc: Raise error in getbalance if minconf is not zero #15729

Closed

maflcko merged commit fabfb79 into bitcoin:master Apr 4, 2019

laanwj removed this from Blockers in High-priority for review Apr 4, 2019

luke-jr reviewed Apr 8, 2019

View reviewed changes

maflcko deleted the 1903-rpcWalletDummySendmany_2 branch April 8, 2019 14:32

vansergen added a commit to vansergen/rpc-bitcoin that referenced this pull request Mar 26, 2020

fix: remove minconf field from sendmany params

0c35cfe

Ref: bitcoin/bitcoin#15596

kwvg added a commit to kwvg/dash that referenced this pull request Dec 4, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

3e789f3

kwvg added a commit to kwvg/dash that referenced this pull request Dec 8, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

469d665

kwvg added a commit to kwvg/dash that referenced this pull request Dec 12, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

5b6b0fb

kwvg added a commit to kwvg/dash that referenced this pull request Dec 13, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

2374cce

kwvg added a commit to kwvg/dash that referenced this pull request Dec 13, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

05c4627

kwvg added a commit to kwvg/dash that referenced this pull request Dec 13, 2021

merge bitcoin#15596: Ignore sendmany::minconf as dummy value

06cc4bb

bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rpc: Ignore sendmany::minconf as dummy value #15596

rpc: Ignore sendmany::minconf as dummy value #15596

maflcko commented Mar 13, 2019 •

edited

promag commented Mar 14, 2019

maflcko commented Mar 14, 2019

practicalswift commented Mar 14, 2019 •

edited

DrahtBot commented Mar 14, 2019 •

edited

maflcko commented Mar 18, 2019

maflcko commented Mar 18, 2019

ryanofsky left a comment •

edited

ryanofsky Mar 20, 2019

maflcko Mar 20, 2019

promag Apr 2, 2019

maflcko Apr 2, 2019

promag Apr 2, 2019

promag Apr 2, 2019 •

edited

jnewbery Apr 2, 2019

promag Apr 2, 2019

maflcko Apr 2, 2019

jnewbery Apr 2, 2019

maflcko commented Mar 20, 2019

ryanofsky left a comment

jnewbery commented Mar 21, 2019

promag commented Mar 22, 2019

jnewbery commented Apr 1, 2019

promag left a comment

maflcko commented Apr 3, 2019

luke-jr Apr 8, 2019

maflcko Apr 8, 2019

gmaxwell commented Nov 24, 2019 •

edited

maflcko commented Nov 24, 2019

jnewbery commented Nov 24, 2019

maflcko commented Nov 24, 2019

gmaxwell commented Nov 24, 2019

rpc: Ignore sendmany::minconf as dummy value #15596

rpc: Ignore sendmany::minconf as dummy value #15596

Conversation

maflcko commented Mar 13, 2019 • edited

promag commented Mar 14, 2019

maflcko commented Mar 14, 2019

practicalswift commented Mar 14, 2019 • edited

DrahtBot commented Mar 14, 2019 • edited

Conflicts

maflcko commented Mar 18, 2019

maflcko commented Mar 18, 2019

ryanofsky left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

promag Apr 2, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

maflcko commented Mar 20, 2019

ryanofsky left a comment

Choose a reason for hiding this comment

jnewbery commented Mar 21, 2019

promag commented Mar 22, 2019

jnewbery commented Apr 1, 2019

promag left a comment

Choose a reason for hiding this comment

maflcko commented Apr 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gmaxwell commented Nov 24, 2019 • edited

maflcko commented Nov 24, 2019

jnewbery commented Nov 24, 2019

maflcko commented Nov 24, 2019

gmaxwell commented Nov 24, 2019

maflcko commented Mar 13, 2019 •

edited

practicalswift commented Mar 14, 2019 •

edited

DrahtBot commented Mar 14, 2019 •

edited

ryanofsky left a comment •

edited

promag Apr 2, 2019 •

edited

gmaxwell commented Nov 24, 2019 •

edited