Concept ACK.

Related: #6570, #7061, #7551

I tend to concept NACK.
What if you want to import 10 addresses? Self-calculate the oldest heigh and pass it in when you import the last address?

IMO the importmulti #7551 call makes more sense maybe there could also be a reason to support the rescanblockchain #7061. But later should not be required if we do #7551 right.

What if you want to import 10 addresses? Self-calculate the oldest heigh and pass it in when you import the last address?

Sure, why not? The current behavior would have it rescan from genesis for the last address, and that behavior will still happen here.

As for importmulti, I agree that would also be good. However, I think that the individual import RPCs should also have the same rescanning behavior that importmulti does.

@achow101:
Right. This is a point.

Either we support no rescan for a single input (maybe together with a manual rescan like #7061) or each address/script/pubkey input call should support the same rescan flexibility.

The question now is if we should support heights or timestamps (key birthday). IIRC discussions in #7061 showed that most devs prefer timestamps.

100% agree with @jonasschnelli, importmulti with explicit key birthdays is the answer here, not adding yet another positional argument to RPC calls (yes, you can also use importmulti to import just one key).
Let's focus on that pull and get it merged.

In time we can deprecate import* in favor of the importmulti interface which can (but doesn't need to) handle multiple keys. There are some other good reasons for that too: see discussion here #7551 (comment) on the importscript confusion.
(and no one generally really wants to import keys one by one and rescan in between)

Agree with @laanwj and @jonasschnelli. For me batch calls are preferred. Still not sure about the name importmulti thou.

But let's not put aside the concept of rescanblockchain. It makes perfect sense to trigger notifications from a specific block/timestamp.

(and no one generally really wants to import keys one by one and rescan in between)

@laanwj true but one can import one by one and then issue the rescan from the correct timestamp.

@promag

true but one can import one by one and then issue the rescan from the correct timestamp.

I agree, but that's inferior in every way to just having one self-contained operation.

I agree, but that's inferior in every way to just having one self-contained operation.

@laanwj well this discussion is like *rawtransaction calls vs createtransaction on steroids. In terms of API it is more desirable to have simple, flexible, self explanatory calls instead of one super configurable call.

However I see this like OpenGL glVertex vs glDrawArrays. There are too much locks and alike in import one by one vs impormulti.

Regarding rescan option, I think it is very reasonable to be in importmulti, but I hope it can be possible to just issue a rescan (for instance #7061).

@promag I think this is a bit different.

If we would have had something like importmulti as the only mechanism for importing, I think nobody would even know the concept of a rescan, which is just an artifact of how wallets used to work (without knowing up to where they were synced, and without birth time).

I think as long as we support/have a rescan RPC call, we should also support an optional "fromheight" argument. We could argue about dropping the rescan call.

Sorry, I meant -rescan as startup option (not as RPC call). IMO we could drop the -rescan startup argument in favor or "importmulti" or/and RPC "rescanblockchain" https://github.com/bitcoin/bitcoin/pull/7061/files

We've talked about changing -rescan to a dummy before, because people would keep on suggesting it as a magic fix for all sorts of problems for years on the forums, while it had absolutely no reason (only when you manually changed your wallet.dat file it would be needed).

Since the introduction of importprivkey without rescan, it became useful again, since it was the only way to import multiple keys without a rescan after each.

I really think we should stop encouraging these crazy schemes that require people to know there is such a thing as a rescan and rely on having blockchain data available. RPC calls should just work, not require hacks to bring the wallet in a consistent state after the fact, with possible atomicity issues.

Concept NACK