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.

Sign up for GitHub

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

Jump to bottom

feat: add page Migrating from 0.X #86

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feat: add page Migrating from 0.X #86

wants to merge 1 commit into from
+213 −1

Conversation

ValuedMammal
Copy link
Contributor

In this PR:

  • Added "Migrating from 0.X" to Getting Started sidebar
  • Added example rust crate migrate-version
  • Updated settings.json and examples/justfile

fixes #81

@ValuedMammal
Copy link
Contributor Author

ValuedMammal commented Dec 2, 2024 •
edited
Loading

Probably could use a snippet of Cargo.toml explaining the dependencies as well as how the use statements are organized.

Edit: Done

@riverKanies
Copy link
Contributor

Looks good to me
but I don't know the inner workings of bdk
I'm curious, are the address indexes really all that's needed to migrate? I'm wondering if it could make sense to just copy over the whole db. It seems to me that there might be a bunch more data (HD wallet stuff) that could get added to the db, but maybe there's not at this point. I could also see copying the db being an issue if the schema is updated in some way, but I'm curious, it wouldn't be an issue related to the amount of data stored right?
I guess maybe just a bit more context on why this is the appropriate approach would be helpful IMO

@ValuedMammal
Copy link
Contributor Author

Someone brought up on discord that a sync might actually be more appropriate here so I made that change in 5cee1e6.

@ValuedMammal
Copy link
Contributor Author

Looks good to me but I don't know the inner workings of bdk I'm curious, are the address indexes really all that's needed to migrate? I'm wondering if it could make sense to just copy over the whole db. It seems to me that there might be a bunch more data (HD wallet stuff) that could get added to the db, but maybe there's not at this point. I could also see copying the db being an issue if the schema is updated in some way, but I'm curious, it wouldn't be an issue related to the amount of data stored right? I guess maybe just a bit more context on why this is the appropriate approach would be helpful IMO

For background this was the original issue bitcoindevkit/bdk#1606.

Yes, the issue is not so much db size but that a lot has changed since 0.X that it would be infeasible to take your old db with you. In fact if you did nothing else but a full_scan with a fresh wallet, it would effectively restore the addresses that have transaction history - the only place where you might get into trouble (and hence this guide) is if you had revealed more addresses using the old wallet but have not yet received payment. In that case you don't want to hand out the same receive address to different parties.

riverKanies
riverKanies reviewed Dec 11, 2024
View reviewed changes
Copy link
Contributor

@riverKanies riverKanies left a comment

Choose a reason for hiding this comment

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

This is great, I'm mainly just requesting some minor language changes for clarification. Even as someone who's worked on bdk for a few months these points weren't super clear to me

docs/getting-started/migrating.md

The below steps are for migrating wallet details from the old [`bdk` v0.30][0] to the new [`bdk_wallet` v1.0][1].
This procedure can be applied to wallets backed by a SQLite database.
Of particular concern is the ability to restore the _last known address index_ for each keychain.
Copy link
Contributor

Choose a reason for hiding this comment

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

This is essentially the only thing we're doing correct? I would personally say something like
"to migrate your wallet data to a new version of bdk, all you essentially need to do is grab the [last used addresses] from the old db, add them to the new db and sync to refetch the rest of the data. Note that we don't need to perform a full scan because we will already have the last used addresses"
To make it extra clear

docs/getting-started/migrating.md Outdated Show resolved Hide resolved
docs/getting-started/migrating.md
bdk_wallet = { version = "=1.0.0-beta.5", features = ["rusqlite"] }
```

Because there are two versions of bdk in the same project, we need to pay attention to how types are imported.
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems like an important note, I would add a subheader here

docs/getting-started/migrating.md

<!-- sync -->
Now that we have a new database and have properly restored our addresses, you will want to sync with the blockchain to recover the wallet's transactions.
Below is an example of doing a `sync` using `bdk_esplora` but the exact method of syncing will depend on your application.
Copy link
Contributor

Choose a reason for hiding this comment

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

personally I would mention again here that a scan is not necessary, just a sync will suffice (since it's not obvious that having the last used addresses is the only difference)

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

@riverKanies riverKanies riverKanies left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add page: Migrating from 0.X
2 participants
@ValuedMammal @riverKanies