Skip to content

Latest commit

 

History

History
53 lines (31 loc) · 5.14 KB

2022-03-16-#24118.md

File metadata and controls

53 lines (31 loc) · 5.14 KB
Raw

PR#24118 - Add 'sendall' RPC née sweep 👀

A PR by Murch to add a simple way of emptying (sweep) a wallet or spending a given set of UTXOs. Participants discussed about the previous toolset (SFFA), what the introduction of this new RPC enables and the specifics of it.

Questions

When would you use sendall and when SFFA? 🔗

  • sendall is to be used when the user wants to use all UTXOs (in the default mode), or a specific subset, to pay a destination.
  • SFFA is to be used when the user wants to use a given budget (max amount) to pay an address but don't want to micromanage UTXOs. Or if the recipient is paying for the fees.
    • With SFFA the input selection is left to the wallet, and the poor recipient may pay for a single input or fifteen, depending on your wallet's UTXO pool composition.
  • Also sendall will never create a change output, while SFFA will totally do that.

A comment suggested that this RPC is potentially unsafe to have. Do you agree with this, and why? 🔗

  • The characterization of unsafe implies there is something that can be exploited/bad even if the user is using it correctly. Which is not true.
  • There is a valid concern about this RPC as unsuspecting users can send an amount larger than they intended—the other send RPCs force the user to specify amount—although not something we need to address.
  • It's a dangerous command, but not unsafe. Also the name implies that it needs to be used with caution.

Why are send_max and inputs exclusive options? 🔗

  • send_max changes the default behavior of spending all UTXOs ("no UTXO left behind"), to maximizing the output amount of the transaction by skipping uneconomic (negative effective value) UTXOs. This is mutually exclusive with providing specific set of inputs as that is manual selection with no intend for maximizing behavior but providing a list of specific UTXOs .
  • They both specify or restrict which UTXOs will be used by the transaction but if you want an explicit set, it wouldn't be completely clear whether you want it forced so, or post-filtered. So we choose to interpret specifying both as an "unclear" and don't proceed.

Why is sendall restricted to spend only confirmed UTXOs? 🔗

  • Spending unconfirmed UTXOs is just more complicated, and it doesn't really align well with the use-case of emptying a wallet completely. If you want to empty it, why are you still receiving new funds to it?
    • If you only spend confirmed you don't have to worry about complexity with replaceable txs.
    • Also if the parent transactions had low feerates, our transaction might have a lower feerate than we aimed for, because Bitcoin Core currently does not bump low feerate parents automagically yet.
  • We also never spend foreign unconfirmed outputs in regular transactions. We just allow to spend unconfirmed change if we're unable to send a transaction otherwise.

Why are there two ways of specifying recipients? 🔗

  • To allow for the use case of doing a payment with some part, and cleaning out the rest.
  • Use case for having multiple recipients with an unspecified amount, that each get the same share:
    • I might know that i want 5 UTXOs in the new wallet , but I don't really want to do the match and right out all the amounts.
    • If you always sweep your wallet at the end of the week between two business partners, or similar.

Looking at the cleanup decorator in the tests, can you guess where in the codebase sendall may find use? 🔗

  • It could be really useful in functional testing, to clean out a wallet between two tests, so that it doesn't have any unwanted UTXOs that might meddle with later tests.
  • The cleanup decorator is a convenient way of defining an after() for all the tests, because we don't have that in the Bitcoin Core python testing framework. @cleanup in particular runs the function, then cleans up the wallet after the test.

How are the fee estimation instructions up for interpretation? Why do we have an extra function to figure out what feerate the user wants us to use? Referring to InterpretFeeEstimationInstructions which was extracted as part of this PR. 🔗

  • Because of use by both send and sendall.
  • These RPCs allow different ways of specifying the fee rate, so the function is used to figure out what the user passed, that no conflicting information was provided and what feerate to take from it.