Keyset v2 migration #1400
Open
Keyset v2 migration #1400
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keysets now expose both V1 and V2 IDs in API responses to support backward compatibility during the keyset ID version migration. V2 keysets can optionally expose their V1 equivalent ID, controlled by the expose_v1_keyset_ids configuration option (default: true). - Add compute_alternate_id to derive V1 <-> V2 IDs - Extend pubkeys and keysets endpoints to return both ID versions - Add keyset lookup by alternate ID for proof verification - Add expose_v1_keyset_ids config option and env var support
- Change new keyset generation to use V2 (Version01) instead of V1
- Preserve original version when reloading existing keysets from DB
- Add comprehensive tests for dual ID exposure:
- pubkeys() and keysets() return both V1/V2 IDs when enabled
- V1 exposure can be disabled to show only V2 IDs
- Runtime toggle via set_v1_id_exposure()
- Keyset lookup works with both IDs for backward compatibility
- Rotated keysets also get dual IDs
- Update existing tests for V2 native keyset behavior
When selecting the active keyset for new proofs, the wallet now prefers
V2 (Version01) keysets over V1 (Version00). Among keysets of the same
version, the one with the lowest fees is selected.
This ensures that when a mint exposes both V1 and V2 keyset IDs for
backward compatibility, the wallet will create new proofs using the
V2 keyset ID, supporting the migration path to V2-only keysets.
Selection priority:
1. V2 keysets (higher version byte) preferred
2. Lowest input_fee_ppk among same version
Changes:
- Update fetch_active_keyset() and get_active_keyset() to use
min_by_key with (Reverse(version), fee) tuple comparison
- Add 10 unit tests covering V2 preference scenarios
thesimplekid
force-pushed
the
keyset_v2_migration
branch
from
ebc060a to
934ef26
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR implements the V2 keyset ID migration strategy for CDK. On the mint side, new keysets are now generated as V2 native (Version01), which includes unit and expiry in the keyset ID hash. For backward compatibility, the mint exposes both V1 and V2 keyset IDs in API responses (/v1/keysets and /v1/keys), controlled by the expose_v1_keyset_ids configuration flag (default: true). This allows existing wallets using V1 IDs to continue operating while new wallets can discover and adopt V2 IDs. The keyset lookup (/v1/keys/{id}) accepts both V1 and V2 IDs regardless of the exposure setting, ensuring tokens with either ID version can always be redeemed. On the wallet side, when selecting an active keyset for creating new proofs (swaps, mints, receives), the wallet now prefers V2 keysets over V1, falling back to fee-based selection among keysets of the same version.
Notes to the reviewers
Suggested CHANGELOG Updates
CHANGED
ADDED
REMOVED
FIXED
Checklist
just final-checkbefore committing