Skip to content

Multi-Keychain-Redo#1

Open
110CodingP wants to merge 4 commits into
masterfrom
multi_keychain_redo
Open

Multi-Keychain-Redo#1
110CodingP wants to merge 4 commits into
masterfrom
multi_keychain_redo

Conversation

@110CodingP

@110CodingP 110CodingP commented Jun 16, 2026

Copy link
Copy Markdown
Owner

Description

Acc to VM's suggestions.

Notes to the reviewers

Particularly need review on

  • KeyRing and its APIs
  • from_v3 and to_v3 (for backwards and forwards compatibility respectively) [tested with a db from v3, check electrum_v3 example.]
  • Merge implementation for ChangeSet.
  • schema_v2, from_sqlite and persist_to_sqlite (in changeset.rs)
  • load_from_params (in wallet/mod.rs)

The KeyRing<K> struct was introduced with the following methods: new,
network, add_descriptor, add_multipath_descriptor,
add_multipath_descriptor_with_range, into_params, list_keychains.
The descriptors field within the KeyRing struct is specifically designed
for O(1) membership checks.

`KeyRing::add_descriptors` was intentionally not included because it is
difficult to provide atomicity guarantees without introducing overly
complicated logic. Also, while `KeyRing::add_multipath_with_range` is
currently internal, it should be made `pub` in the future if we can
incorporate a generic range parameter in an elegant manner.
Introduced `InitError` to report errors at the time of `Wallet` creation
since `DescriptorError` does not report duplicate keychains case now.
Also introduced `MissingKeychain` error to report the case when address
APIs are called with an invalid keychain.
`CreateParams::multi_path_descriptor_with_range` follows the logic of
`KeyRing::add_multipath_descriptor_with_range`.

Removed `ExternalAndInternalAreTheSame` variant from `Error` in
`descriptor` in order to avoid propagating the generic to
`IntoWalletDescriptor`. Also maintaining whether keychains are the same
should be the concern of the `Wallet` level and not the descriptor
level.

The `from_v3` and `to_v3` APIs are for backwards and forward
compatibility respectively such that the `load_from_params` does not
need to deal with 2 separate types of `ChangeSets`. Users should call
these APIs appropriately. `load_from_v3`, `load_from_v3_async`,
`persist_to_v3`, and `persist_to_v3_async` have been added to
`PersistedWallet` for users convenience.

Refactor of export.rs is NOT COMPLETE.

`Utxo` and `WeightedUtxo` were primarily used in `TxBuilder` contexts so
they still use `KeychainKind`. Note we have decided that transaction
building for multi-keychain `Wallet` will only happen through
`create_psbt` API.

`Merge` implementation for `ChangeSet` does not take into account the
`descriptor` and `change_descriptor` fields because ideally `v4`
completely ignores these fields.

But `from_sqlite` and `persist_to_sqlite` still load and persist these
two fields for backwards/forwards compatibility.
The tests related to signers are yet to be fixed completely.
The new example (electrum_v3) is just for testing purposes and should be
removed from the final version of the commit.
@110CodingP 110CodingP force-pushed the multi_keychain_redo branch from fa470d1 to 3b89212 Compare June 23, 2026 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant