Add helper methods to help migration from 0.X versions

[thunderbiscuit]

The current migration from a 0.X to a 2.0 wallet requires 1 important piece of data: the last revealed index of the wallet. See our docs on migrating.

This is problematic for applications because it means they need to ship (1) the old version of BDK as part of their update (so they can create the old wallet and call Wallet::get_address to see what is the last revealed index), and (2) the new version of bdk_wallet to create the new wallet and use it.

Because applications often don't know which version of their app will perform the upgrade (people skip versions, etc.), they will have to basically forever ship with both versions of BDK to handle that migration.

There is a potential solution to this, and it involves looking at the old SQLite database directly and fetching the last revealed index from it directly, but this approach would need to be certain that all previous versions of the bdk sqlite database are in fact using the same schema (since at heart the db file was never devised to be used by users directly, but rather always by the wallet).

Moving forward, methods on constructors like Wallet::from_previous_bdk_version_db (needs better naming of course) would simplify this migration greatly and would ensure applications can be confident in their upgrade to the newer versions of bdk_wallet.

[GideonBature]

I strongly support this feature proposal @thunderbiscuit. It would improve the dev. experience by removing the need for dual dependencies (bdk & bdk_wallet).

To address the concern about schema stability, I suggest that we begin by analyzing the database schemas of the last major 0.X releases. If the schema for storing the derivation index is consistent, the implementation should be straightforward else, we will have to be certain that for all previous versions of bdk sqlite database are using same schema..

We could implement a new constructor like Wallet::create_from_legacy_db. Internally, it would connect to the old database via rusqlite, run a direct SQL query to fetch the last revealed indices for the external and internal keychains, and then use that information to initialize the new wallet state. This I believe will encapsulate the entire migration logic into a single, clean function call.

I will continue my research on this to see how best to go about it, so that once we have agreed on the possible way to go about this, I can jump on it.

[tnull]

With bdk_wallet 1.0 approaching its one-year anniversary, are we positive there are (m)any users left on 0.X that would benefit from this feature?

I was strongly in favor of providing migration logic as part of the 1.0 release, but it never shipped. Now I'm honestly dubious if it's still worth the effort as most users likely already wrote their own migration logic (or left it to downstream users like we did - resulting in intermittently 'lost' funds 😬).

[thunderbiscuit]

Yeah whether it's worth the effort we'll have to think about (again they might be able to just pull the number from the db directly).

But for production users I think it's unfortunate but there are maybe more than we think. I spoke to Peach Wallet last week and that was one of their hesitations, and I know that BitKey is still on the 0.X release. So that's 2. bdk-rn and bdk-flutter are both still on 0.X, so any users of those.