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
Conversation
Concept ACK (Haven't really looked at the code). Possible extension: |
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. |
Hmm, what about extending RPC |
sweepprivkeys is intended for users, and not to import keys. Users should never use importprivkey. |
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.)
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.)
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.)
Github-Pull: bitcoin#9152 Rebased-From: 220750dc4aa298d806effd4c6d3685721dd53a88
…function Github-Pull: bitcoin#9152 Rebased-From: 4437a5f875da68032f9539e35679219f316cc851
…allet Github-Pull: bitcoin#9152 Rebased-From: fdc677846eb381427c2b6382c5e1b88568311f9f
There was a problem hiding this 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.
src/wallet/rpcwallet.cpp
Outdated
LOCK(cs_main); | ||
mempool.FindScriptPubKey(setscriptSearch, mapcoins); | ||
FlushStateToDisk(); | ||
pcoinsTip->FindScriptPubKey(setscriptSearch, mapcoins); |
There was a problem hiding this comment.
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.
Github-Pull: bitcoin#9152 Rebased-From: dd089adf87ea6078d1883ce1b4771760bfda1ddb
Github-Pull: bitcoin#9152 Rebased-From: ed604747289c12d605f219b3f859a9bef376174e
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.)
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.)
25793ce
to
f6c9c12
Compare
Concept ACK.
Please don't do this. People confuse |
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.)
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.)
Seems this won't be making it for 0.15. Untagging. |
Concept Re-ACK. Needs rebase. I guess this is also something we could want for 0.16. |
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(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be const reference?
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 ( |
e341211
to
fe16fc5
Compare
…et is synced before we return
I'm afraid this PR doesn't build when rebased on |
Needs rebase |
Concept ACK |
This should probably use "scantxoutset" internally (rebase issue). |
There was a problem hiding this 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", |
There was a problem hiding this comment.
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)?
I don't see any sane way to rebase this post- |
I don't think it should be too bad if someone wants to pick it up. It should just require a new |
Maintainers maybe remove "Waiting for author" and "Needs rebase" tags and mark "Up for grabs" |
Does this look like a good approach?
TODO:
RPC testsNOTE: Currently needs #14602 for tests to pass