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.

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

[Bug] DID Recovery Hash Lost in Upgrade Spend During Special Circumstances #19152

Open
BrandtH22 opened this issue Jan 14, 2025 · 1 comment
Open
Labels
bug Something isn't working stale-issue flagged as stale and will be closed in 7 days if not updated Wallet

Comments

@BrandtH22
Copy link
Contributor

BrandtH22 commented Jan 14, 2025

What happened?

The recovery list can at times be lost creating the need for users to create specialized spend bundles to interact with the DID. Issue arises when the user has previously added the recovery options, resyncs the wallet which fails to properly sync the updated recovery list, then runs an update spend (ex. nft set_did).

Theoretical steps to reproduce (note not able to actually reproduce yet):

  1. Setting up a DID with recovery
  2. Clearing out the state and importing into a fresh wallet
  3. The recovery list isn't properly loaded (but num_verifications is still 1)
  4. Doing an update spend

In this case the user is unable to spend their DID for other actions and when running the find_lost did command will get an error similar to:

`Failed to find lost DID: RPC response failure:
 {"error": "Cannot recover DID <redacted> because the last spend updated recovery_list_hash/num_verification/metadata.", "success": false}

Note - the workaround below did not resolve the issues, rigidity ended up needing to build a custom spend bundle for the user to sign and submit which updated the recovery hash back to what it is intended to be.

The current workaround is to have the user run the find_lost did command with the following:

- recovery hash as the current listed (in this case it should be `4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a` | the hash of 1 since this is a tree hash)
- num_verifications set to that which they configured (should also be reflected onchain)
- did_id as the did_id

This will look similar to:
`chia wallet did find_lost -id did:chia:133xtshe8ckqmlcjg7p9fytrzzz0vkqt4jsv8w87nm3mka93cstvqpp5920 -n 1 -r 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a`

Recommendations for a solution:

  • short term: (proposed by Rigidity) change the update spend logic to reuse the existing recovery hash/metadata/etc synced from the chain rather than trying to recreate it from a recovery list

Version

2.5

What platform are you using?

Windows

What ui mode are you using?

GUI

Relevant log output

No response

Copy link
Contributor

This issue has not been updated in 14 days and is now flagged as stale. If this issue is still affecting you and in need of further review, please comment on it with an update to keep it from auto closing in 7 days.

@github-actions github-actions bot added the stale-issue flagged as stale and will be closed in 7 days if not updated label Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale-issue flagged as stale and will be closed in 7 days if not updated Wallet
Projects
None yet
Development

No branches or pull requests

2 participants