[Wallet] add rescanblockchain <height> RPC command #7061

Closed
wants to merge 3 commits into
from

Projects

None yet

10 participants

@jonasschnelli
Member

Related, similar to #6570.

I had to import some addresses and didn't want to rescan from genesis.
Not sure if this was already discussed.

@laanwj
Member
laanwj commented Nov 19, 2015

I'd rather have it that the API is such that an explicit rescan is never needed. Wasn't there some work on a multi-import w/ timestamps?

@jonasschnelli
Member

Yes. There is a PR (see PR description). I agree that it would be better to avoid rescans at all, although it might be complicated to catch all edge-cases and a manual trigger can help in situations where someone needs to deal with multiple/complex imports (you only want to do one rescan).

And I think some people will cancel a rescan because they want to do other stuff and/or had not considered that a rescan can take a long time. Afterward calling -rescan (from genesis) is a time consuming option.

@laanwj
Member
laanwj commented Nov 19, 2015

But manually specifying a block # to rescan from is extremely fragile... it's very easy to get this wrong.

Also, rescanning doesn't interact with pruning which will be more and more common in the future.

@gmaxwell
Member

@lannwj I thought thats part of what the height parameter here was for-- addressing pruning comparability?

@petertodd
Member

How about we call this rescanfromheight instead, to make it possible to add a rescanfromtime later if users demand? Equally, some kind of RPC call that finds the first block with a nTime after a specific time might be useful here.

Do we have a way of querying what block # is the oldest non-pruned block?

@petertodd
Member

It also occurs to me that for this usecase we might instead want to have pruning not happen automatically, but rather be an on-demand thing where the user specifies the oldest time they're interested in.

@gmaxwell
Member

So the biggest negative I personally see here is that it furthers this misunderstanding that rescan is some thing users generally need to be doing. Until we added these non-rescan imports a user initiated rescan is something that never should have been needed (and indicated a serious bug we'd like to know about if it was). As a result of the -rescan argument there is now this whole cargo cult of people that rescan every time they're scarred by a shadow. I hate to further that.

But I can't deny how really useful this will be.

@petertodd
Member

@gmaxwell A possible way around that would be to make the rescan check if you have any addresses that haven't yet been scanned in that range and error out if not. (basically make it say "no rescan needed")

@gmaxwell
Member

Hm. this could also take a stop argument, allowing you to scan single blocks or avoid rescan overlap. Also, I think all the wallet re-scanning should traverse its interval backwards-- for more instant gratification; though this would dork with the wallet transaction ordering... actually import at all breaks that, I should go talk to luke-jr about that.

@promag promag and 1 other commented on an outdated diff Nov 23, 2015
src/wallet/rpcdump.cpp
+ + HelpExampleRpc("rescanblockchain", "\"100000\"")
+ );
+
+ LOCK2(cs_main, pwalletMain->cs_wallet);
+
+ CBlockIndex *pIndexRescan = NULL;
+ if (params.size() > 0 && params[0].isNum())
+ pIndexRescan = chainActive[params[0].get_int()];
+
+ if (!pIndexRescan)
+ pIndexRescan = chainActive.Genesis();
+
+ //We can't rescan beyond non-pruned blocks, stop and throw an error
+ if (fPruneMode)
+ {
+ if (fPruneMode)
@promag
promag Nov 23, 2015 Contributor

Remove?

@jonasschnelli
jonasschnelli Nov 24, 2015 Member

Oops. A rebase issue. Thanks for point out. Fixed.

@pstratem
Contributor

agree with gmaxwell that this should scan a range of blocks

@jonasschnelli
Member

Agree with the stop parameter. Working on a implementation....

@sipa
Member
sipa commented Nov 24, 2015

I would still prefer an approach that imports with birthdate instead of explicit rescanning.

@jonasschnelli
Member

Added a commit that allows providing a optional parameter with a height where the rescan should stop.

@sipa: I agree that rescan height over a key/address birthday would be nice to have (see #6570). But a explicit rescan RPC call can be useful IMO. It's trivial to maintain and it can save lots of rescan-time on the user side. But agree, it has to be considered as "experts" feature.

What about implementing a threshold for autodetecting wether the parameter is a blockheight or timestamp (similar to LOCKTIME_THRESHOLD)?

@promag
Contributor
promag commented Nov 24, 2015

@jonasschnelli see #6570 (comment) regarding your last comment.

@GIJensen
GIJensen commented Dec 7, 2015

ACK

@mrbandrews
Contributor

If this is still moving forward - I tested it a bit (including pruned mode) and it looks fine to me. One suggestion is to make the start-height a required parameter so that the user specifies "rescanblockchain 1" to scan from genesis. If the start-height is < 1 or higher than current height, throw an error.
Otherwise, ACK.

@promag promag commented on the diff May 2, 2016
src/wallet/wallet.cpp
@@ -1084,6 +1087,8 @@ int CWallet::ScanForWalletTransactions(CBlockIndex* pindexStart, bool fUpdate)
if (AddToWalletIfInvolvingMe(tx, &block, fUpdate))
ret++;
}
+ if (pindex == pindexStop)
@promag
promag May 2, 2016 Contributor

Move to while condition?

@promag
promag May 2, 2016 Contributor

Because it's inclusive?

@laanwj laanwj added the Feature label Jun 16, 2016
@luke-jr luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 28, 2016
@luke-jr luke-jr Merge #7061 jonas/2015/11/wallet_rescan_rpc 8c521c7
jonasschnelli added some commits Nov 19, 2015
@jonasschnelli jonasschnelli [Wallet] add rescanblockchain <height> RPC command ff30b2f
@jonasschnelli jonasschnelli [Wallet] don't allow rescanblockchain beyond pruned height 15490e7
@jonasschnelli jonasschnelli ScanForWalletTransactions: add option for a "stop height" d1aa8a9
@jonasschnelli
Member

Rebased.
I think there are still reasons to consider that PR. At the moment, it would really be useful. Even once we have #7551 (importmulti) it could see use cases for rescanblockchain.

@sipa
Member
sipa commented Aug 25, 2016

This seems better #7984, but I still prefer not furthering the usage of various rescans. We need APIs that don't require users to keep track of the concept of rescanning IMHO.

@jonasschnelli
Member

I agree. Ideally, there will be no need to rescan. But in practice, rescans are sometimes required (I guess everyone who gave some users support has encountered that). IMO a rpc rescan commend with an optional hight is much more flexible then -rescan as a startup argument.

@sipa
Member
sipa commented Aug 25, 2016

I think we should work on importmulti instead (or at least an importprivkey that takes a key birthdate as parameter), not on more ways to rescan.

@jonasschnelli
Member

I think we should work on importmulti instead (or at least an importprivkey that takes a key birthdate as parameter), not on more ways to rescan.

Yes. I can agree with that.

@jonasschnelli
Member

Another thing where this could be useful is restoring hd wallets

@MarcoFalke
Member

Since importmulti #7551 is merged, some use cases are covered by that.

@laanwj
Member
laanwj commented Nov 2, 2016

I think we should work on importmulti instead (or at least an importprivkey that takes a key birthdate as parameter), not on more ways to rescan.

Tend to agree. Closing this for now.

@laanwj laanwj closed this Nov 2, 2016
@jonasschnelli
Member

IMO something like that would be very handy if you rescan a HD wallet (old backup).
-rescan does not allow direct user feedback
IMO rescanning an old HD backup should by default start at the height where we introduces HD (optional down to genesis).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment