wolfmcnally
commented
2 years ago I think I'd need to see some user stories to understand how this should best be implemented.
Open ChristopherA opened 2 years ago
wolfmcnally
commented
2 years ago I think I'd need to see some user stories to understand how this should best be implemented.
shannona
commented
2 years ago @ChristopherA let me know if this matches your vision and if there's anything else we want to think about while (generally) writing user stories.
Fundamental Goal: Make it easy for a user to recover his SSKR shares.
Starting Position: Bob lost one of the active keys from his 2-of-3 multisig. To recover his funds (sweeping them to a new address), he must first reconstruct his recovery key, which has been sharded out to 5 friends, with a threshold of 3. A cover sheet for the SSKR sharding will help with the reconstruction because it shows a list of checksums for the shares and Bob has written in initials for who has each. In addition, Bob will use Gordian Seed Tool ("GST") to manage the recovery of shares.
Story: Bob recovers the cover sheet for his SSKR from his home storage and looks over the list of shares, which is marked with initials of people to whom he's given shares. He choose "AA" first, which is Alice. He shows her the QR crypto-request for the SSKR, also printed on the cover sheet. She reads that into her Share Tool app[^1], and it responds with a stored QR. Bob reads that into Seed Tool with the scan QR functionality, and Seed Tool tells him "Success! One share has been scanned. Scan two more to restore [OIB that matches one on cover sheet]". Seed Tool then generates a new QR that will allow Bob to continue hunting down his shares.
Next up is "OO", or Oscar. Bob shows Oscar the new QR, but Oscar's Share Tool tells him "Your share has already been scanned. You have no new shares to help reconstruct this seed." Somehow Oscar ended up with the same share as Alice! And, his Share Tool immediately knew because of the updated QR[^2].
Whoops! Fortunately there are three more shares.
Carol doesn't have a new fangled Share Tool, just the coupons that Bob printed. So, they're not responses, just SSKR URs. She shows Bob one of them, and he gets the warning. "Warning! This share is not part of the seed you're reconstructing. Do you want to scan it anyway?"[^3] Bob opts not to and tells Alice that isn't the right share. It turns out that he's issued shares to his friends a few times and Carol has just been stacking them up. Bob searches through Carol's shares to find the one whose checksum matches what's printed on his cover sheet next to the initials "CC". He finds it, scans it, and gets "Success! Two shares have been scanned. Scan one more to restore [OIB]." Seed Tool also generates a new QR that will allow Bob to capture the last share.
That's with Dan. No drama here. Bob shows Dan the QR, Dan reads it into Share Tool, and it outputs the share that Bob needed. "Success! Your seed has been reconstructed. Click 'save' to store it."
[^1]: Obviously, Share Tool is imaginary. This raises the question of what can actually read crypto-requests for SSKR shares, which seems like a vital part of this story.
[^2]: For this to work as depicted, the QR would have to include a list of already-scored shards. The other option is for Oscar's Share Tool to dumbly send its share and for Seed Tool to be what notifies them that the share is already possessed. However, the depicted scenario seems superior because it could help guide other situations, such as if Oscar had two shares, the repeat and a new one.
[^3]: What happens if you scan the new, wrong seed? My guess is that Seed Tool would have to drop the old reconstruction and start a new one if Bob says yes, and if so we'd need to warn him further ("WARNING! This will end your current reconstruction, losing the XX seeds that you have already scanned."). But I suppose not if Seed Tool were to have some transient way to store partially reconstructed seeds. That just seems dangerous, though. In any case, this needs to be considered before finalizing a user story.
ChristopherA
commented
2 years ago Not sure if this should be a 1.5 or a 1.6 item.
I'd like to see the ability for Gordian SeedTool to be able to request an SSKR.
four forms:
Initial user-facing features would be:
*Each SSKR printed cover page would have a crypto-request for its issued QRS.
Scan an initial SSKR share and SeedTool will request additional SSKRs with a QR crypto-request displayed in its UX, as well as accept a scan of another SSKR even if not from a crypto-response, and warn if it is not part of the set.
(optional) store SSKR identifiers issued with master seed and master public key info,
The ideal is that if someone has an offline copy of the SSKR cover sheet, they can initiate the process to restore the seed.
I recognize there are state and metadata dependencies in SeedTool that likely have to be implemented first, and it is likely that we should do crypto-envelope first.