Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet/RPC: sweepprivkeys method to scan UTXO set and send to local wallet #9152

Closed
wants to merge 6 commits into from

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Nov 13, 2016

Does this look like a good approach?

TODO:

  • rawtransaction sweep functionality
  • GUI sweep (Receive tab?)
  • abstract shared sweep logic
  • RPC tests

NOTE: Currently needs #14602 for tests to pass

@jonasschnelli
Copy link
Contributor

Concept ACK (Haven't really looked at the code).
I think a sweep function would be a great feature. One could import "old" private keys into a new HD wallet for example.

Possible extension: sweepseed could be an extended version of that, moving all funds form a HD seed to a new one, generating large lookup-windows on different chainpathes. It could also be UTXO set only not requiring a -rescan.

@gmaxwell
Copy link
Contributor

From a raw flow perspective, the generation of the sweep transaction is something that works from public information and should be possible on an online node without access to the private keys... so that one should be a 'createrawsweeptransaction' which takes a list of adresses/pubkeys/redeemscripts (and maybe private keys ... maybe some kind of BIP32 chain spec) and returns a transaction that spends all coins assigned to matching keys, potentially with arguments to limit the set of inputs collected.

@paveljanik
Copy link
Contributor

Hmm, what about extending RPC importprivkey with another optional argument sweep defaulting to false?

@luke-jr
Copy link
Member Author

luke-jr commented Nov 17, 2016

sweepprivkeys is intended for users, and not to import keys. Users should never use importprivkey.

ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Dec 9, 2016
Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Dec 15, 2016
Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Dec 19, 2016
Make CCoinsViewCache::Cursor() return latest data

Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 21, 2016
Github-Pull: bitcoin#9152
Rebased-From: 220750dc4aa298d806effd4c6d3685721dd53a88
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 21, 2016
…function

Github-Pull: bitcoin#9152
Rebased-From: 4437a5f875da68032f9539e35679219f316cc851
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 21, 2016
…allet

Github-Pull: bitcoin#9152
Rebased-From: fdc677846eb381427c2b6382c5e1b88568311f9f
Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: "Refactor sweepprivkeys to deal with CCoinsView::Cursor limitations," I think I could extend #9306 to return a working cursor for CCoinsViewMemPool, if that would help.

LOCK(cs_main);
mempool.FindScriptPubKey(setscriptSearch, mapcoins);
FlushStateToDisk();
pcoinsTip->FindScriptPubKey(setscriptSearch, mapcoins);
Copy link
Contributor

@ryanofsky ryanofsky Dec 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be appropriate to loop over mapCoins calling CTxMemPool::pruneSpent, on each entry, to avoid trying to sweep from an output that is already in the process of being spent.

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 31, 2016
Github-Pull: bitcoin#9152
Rebased-From: dd089adf87ea6078d1883ce1b4771760bfda1ddb
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Dec 31, 2016
Github-Pull: bitcoin#9152
Rebased-From: ed604747289c12d605f219b3f859a9bef376174e
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Jan 2, 2017
Make CCoinsViewCache::Cursor() return latest data

Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Jan 2, 2017
Make CCoinsViewCache::Cursor() return latest data

Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
@luke-jr luke-jr force-pushed the sweepprivkeys branch 2 times, most recently from 25793ce to f6c9c12 Compare February 7, 2017 03:11
@laanwj
Copy link
Member

laanwj commented Feb 27, 2017

Concept ACK.

Hmm, what about extending RPC importprivkey with another optional argument sweep defaulting to false?

Please don't do this. People confuse import and sweep all over the place. The least we can do is make them separate RPCs with separate documentation.

@laanwj laanwj added this to the 0.15.0 milestone Feb 27, 2017
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Jun 2, 2017
Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Jun 12, 2017
Change CCoinsViewCache::Cursor() method to return a cursor yielding the latest
CCoins entries, instead of just previous entries prior to the last cache flush.

The CCoinsViewCache::Cursor method is not currently used. This change just
enables new features that rely on scanning the UXTO set to work correctly (for
example bitcoin#9152, which adds a
sweepprivkeys RPC, and bitcoin#9137, which
improves handling of imported keys for nodes with pruning enabled.)
@sipa
Copy link
Member

sipa commented Jul 12, 2017

Seems this won't be making it for 0.15. Untagging.

@sipa sipa removed this from the 0.15.0 milestone Jul 12, 2017
@jonasschnelli
Copy link
Contributor

Concept Re-ACK. Needs rebase. I guess this is also something we could want for 0.16.
I have no strong opinion about sweep versus createrawsweep. The approach we took for bumpfee was also to do the non raw one first, although I agree that the ramification of sweep is different then a bump.

@luke-jr
Copy link
Member Author

luke-jr commented Aug 19, 2017

Rebased and added a simple functional test.

const UniValue& privkeys_a = optval.get_array();
for (size_t privkey_i = 0; privkey_i < privkeys_a.size(); ++privkey_i) {
const UniValue& privkey_wif = privkeys_a[privkey_i];
std::string wif_secret = privkey_wif.get_str();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be const reference?

@meshcollider
Copy link
Contributor

Concept ACK. Still needs rebase. IMO this should be reworked to take a descriptor which would address the points above about accepting pubkeys/HD keys. Agree that returning the raw transaction is preferable (createrawsweeptransaction)

@practicalswift
Copy link
Contributor

I'm afraid this PR doesn't build when rebased on master.

@DrahtBot
Copy link
Contributor

DrahtBot commented Jun 6, 2019

Needs rebase

@practicalswift
Copy link
Contributor

Concept ACK

@jonasschnelli
Copy link
Contributor

This should probably use "scantxoutset" internally (rebase issue).
I also think it should be a createrawsweep call (rather then directly signing and executing).
Maybe you can change this to be an argument for "scantxoutset" that would also spit out a rawtransaction (with configurable fee and eventually configurable target address) for the sweep transaction.

Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK. Using scantxoutset internally seems like a good idea. It needs a fee control option, could be as simple as feeRate with 1 sat/byte default. Ideally also RBF control, but that can wait for a followup.

As mentioned by others, it's good to be able to inspect the transaction. That could just be another option. In #16378 I introduce a add_to_wallet to option, and the RPC call returns a hex & PSBT if false.

Another potential followup could add descriptor support; those can have private keys now too. Others above suggest using those instead of WIF, but I think an array of WIFs is still common enough to be worth supporting directly.

This PR sweeps into the wallet itself. A followup could sweep into any arbitrary descriptor, which would make migrating wallets to some new scheme easier, e.g. moving from single-sig to multi-sig without joining UTXOs.

if (request.fHelp || request.params.size() != 1) {
throw std::runtime_error(
RPCHelpMan{"sweepprivkeys",
"\nSends bitcoins controlled by private key to specified destinations.\n",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This says "specified destinations" but you can't specify the destinations. Can you also make it clear that coins are sweeped one by one to unique addresses (per priv key)?

@luke-jr
Copy link
Member Author

luke-jr commented Oct 14, 2019

I don't see any sane way to rebase this post-bitcoin-wallet, so going to have to just make it a Knots-only hack for now. :/

@luke-jr luke-jr closed this Oct 14, 2019
@ryanofsky
Copy link
Contributor

I don't see any sane way to rebase this post-bitcoin-wallet

I don't think it should be too bad if someone wants to pick it up. It should just require a new interfaces::Chain method to wrap FindScriptPubKey calls, since wallet code can no longer access mempool and pcoinsdbview globals directly.

@ryanofsky
Copy link
Contributor

Maintainers maybe remove "Waiting for author" and "Needs rebase" tags and mark "Up for grabs"

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet