Edit (20th Jan): Just realised (maybe after resting properly yesterday), that a transfer of funds is not even required as with the initial setup below. All that's required, is that the full seed be decrypted after entering in the old key, and re-encrypted with the new key (derived from the new password - no part of the seed is dependant on the password any more with the new setup) and sent to the server to be stored.

This is better for users as they don't need to re-backup their full seed if they reset their password and if they've imported the full seed into another wallet, they don't need to do that again either.

Revision of the initial split seed mechanics here...

https://read.cash/@tibanne/split-seed-mechanics-39d15b5d

Our project has evolved quite a bit throughout the course of the hackathon based on various feedback. At the bottom of this update are our two new diagrams which resemble the current state of SplitSeed... which probably needs a new name now, as the seed is no longer being split.

Existing work included a very different version of the split seed scheme implemented into the registration and login flows of sharetip.me.

Work done during the hackathon included recoding the registration and login flows to work with the revised version and then implementing from scratch the password reset flow including the generation of recovery PDFs.

EDIT: this is the only edit done below after submission time... "The main concern one should have when deriving the seed" -> "The main concern one should have when allowing the seed to be fetched and decrypted"

The main concern one should have when allowing the seed to be fetched and decrypted using entropy from a password is 1) the complexity of the password, and 2) whether the password or hash thereof has been exposed publicly by a hack on another website.

In our opinion there are a few ways to combat 2) to prevent malicious actors from taking advantage of people who've been pwned. a) Check if they've been pwned on registration and convince them to start using a password manager. b) On device change (using a device code stored in local storage and sent the the server to see if it's on a list for that user), make sure that you check they own their email by sending them a code or a magic link in addition to requiring their password.

To combat 1) we've used a client side javascript library to check if the password is of an entropy greater than a selected threshold.

Latest User Flow Diagram:

Latest Scheme diagram:

We look forward to feedback from this submission and it's the reason we entered the hackathon... to make this robust! Thanks for your time.