Onboarding and Key Management w/ Implicit Accounts

[heycorwin]

After exploring several directions towards the aim of supporting both implicit accounts and Torus in the next iteration of our onboarding UX, we've surfaced a few critical unknowns. I'd like to see if we can gain some clarity around these to unblock the work. Following are a few questions, scenarios, and/or considerations.

1. Implicit Accounts with a 0 balance: This item has been on our roadmap for > 2 months. The problem with how accounts are implemented currently is that they require storage to occupy space on-chain. It has been suggested that implicit accounts may offer a way to circumvent this by enabling a user to be "logged in" to the wallet without first having to fund the account, since the concerns of a limited namespace are absent. For the next iteration of our onboarding UX, we need a final word on the feasibility of this functionality. Is it feasible to allow users creating an account using an implicit address to reach a "logged in" state without having to fund the account first?

2. Resume Onboarding & Recycling Keys: A tangential problem exists when considering the need for users to resume onboarding, or to enable them to navigate back to a wallet account that has yet to be funded. We currently provide users with their private key before the account has been created. With implicit accounts, it makes sense then that as long as the user is in possession of their private key, they should be able to return to their account, even if they have not yet funded it. This brings into question the concept of recycling keys. Consider the following scenario: A user begins account creation and reaches the funding step. Inevitably, some users will decide not to fund the account right away. Expecting to be able to reach their account later on, they may attempt to use their seed phrase to "recover" the account in order to do this. Currently, since the account does not exist on chain, they will encounter an error that says the key is invalid. Theoretically, since a private key pair will generate a unique implicit address, we could derive the implicit account from a user who has provided their private key, deriving the same address consistently even if they have yet to fund the account. However, we need to consider what this means for keys that have been used before. If a key was previously used for an account (even a named account), but was removed and is now not attached to any account, we could in theory again derive the implicit account from this key were the user to provide it. This idea of "recycling" keys is something that has not been discussed at length. Is there any risk associated with this action? Are there any clear reasons why this should be avoided?

3. Torus Limitations: By default, Torus maps a single email address to a single private key. Consider the nature of implicit accounts: since an implicit account is unique to a private key, this means that if Torus can only generate a single private key per email or social login, then it can only be used to create a single implicit account. If a user attempts to create a new implicit account using Torus after they have done so once already, it is likely they would be prevented from doing so.

Unless...

4. Generating Multiple Implicit Accounts from a Single Private Key: It is common practice for wallets across the industry to leverage hardened derivation to derive multiple implicit addresses from a single private key. Similar to Ledger, where HD paths can be used to generate a unique address for each path index, Seed Phrases can also leverage HD paths to derive multiple addresses. This enables a single key to be used to secure multiple addresses. The biggest challenge here becomes determining how to find these accounts during an import. The defecto solution for most wallets is to leverage an algorithm to iterate over the HD path indices, importing each account with any kind of activity. Once a predefined number of accounts in the array are scanned that have no activity, the algorithm stops. An outline for this approach and process can be seen here: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit, and is the approach used by a large majority of crypto wallets.

As we prepare to incorporate implicit addresses, we should take this into consideration. If we make a decision to limit a user to a single implicit account per private key (HDpath[0]), this means then that the user will need to secure and manage a unique private key for every address they decide to create. While this is very secure in theory, it could also be argued that a user managing many "paper wallets" is forced to endure larger cognitive load and complexity in managing their keys and accounts, which could result in increased risk that they lose the keys for one or more accounts. This would also result in objectively subpar onboarding, since every time the user creates an account, they would need to generate a new private key pair.

Since NEAR natively offers the ability to change and rotate keys on a given account, it stands to reason then that we should not force users to generate a new private key each time they want to generate a new implicit address. Users should be allowed to secure and derive multiple implicit accounts from a single private key. They should also retain the ability to generate new accounts with a fresh key, if that is something they desire or need.

The question is, is the implicit address generated in this scenario derived from an existing key using the common HD path solution, or by some other means?

One last thing to consider is that we currently support the importing of accounts from multiple HD paths from a Ledger device. We will also be enabling users to define which HD path they use when creating accounts. It therefore stands to reason that similar behavior could be useful when leveraging other security methods.

[stefanopepe]

Thanks Corwin! I'll answer mostly from a product perspective:

1. I believe we have to remove the funding step from the onboarding process, and let users access the dashboard showing zero balance. This is common also with web2 applications, like Vemo or even banks like N26 or Revolut. If a specific action requires a spendable balance (login to a dapp, receive fungible tokens) we might offer a "technicolor activation journey" specifically built to fund the wallet, abandon a "grey zero balance" dashboard, and begin to get engaged.

2. This was discussed multiple times, and a source of trouble in the support channels: the wallet should "remember" where the user left a creation journey, keeping at least a trace of the originally generated account ID/implicit account. This functionality would ignore on-chain information, keeping this state within the browser storage/cookies. We can safely assume that users won't switch devices/browsers expecting to resume their wallet creation >> if that's the case, they have to start over.

3. I support the idea of using Torus as a "master key" in the very same way we use Ledger, with HD paths and derivations from the same seed. I don't think it's technically possible - normally the seed is way longer than a single private key and we may require to call an endpoint on Torus' side to get the correct HD path (as it is today with Ledger) - HOWEVER, NEAR Protocol can have the same public key associated with multiple accounts. While this is an anti-pattern for privacy & implicit account derivation (and might be for the security), I would prefer having the same Torus key on multiple low-value named accounts rather than multiple Torus email addresses, each of them associated with different wallets... I would end up keeping all Torus' seeds in the same place, using email+1@gmail, email+2@gmail, and so on...

4. I strongly support this idea, but outside of the webwallet codebase. Having this stuff happening inside a browser does not sound right and sustainable from a security standpoint. We are already discussing, from multiple angles, the creation of a "signer mobile app" that would contain this fundamental functionality, and have a "dumb-browser" that can only see this application as it today can see the Ledger Nano. Technically, the PoC would act the same as the Ledger, including the HD selection path and the connection detection.

I would add, supporting #4, that derivation path with NEAR would be even more human-friendly than what we are used to: we can easily replace an anonymous HDpath[0] information with human-readable list of named accounts, likesatoshi.near, and let the user "match" only the accounts he wants to use.
This would be even better with read-only accounts and the idea that our webwallet should become a "fancy explorer" with the ability to ask for signatures on external devices and/or services...

[heycorwin]

We can safely assume that users won't switch devices/browsers expecting to resume their wallet creation >> if that's the case, they have to start over.

Well, if we don't require the funding step for an implicit address, then I think this point is moot. That being said, I don't think it's necessarily safe to assume this. I think the local storage / cookie option is a start, but I think that we have to assume that if we give a user their seed/private key, and then progress them to a logged in state with a 0 balance, they are likely to attempt to recover their account on another device.

Consider this scenario: I do my account creation on my phone while I'm out and about, resulting in an implicit account with a 0 balance. I get home, and while on my computer decide that I am ready to fund my account, since it's easier to transfer funds from my bank and use an exchange on my PC. I open up the wallet in my browser and input the recovery phrase that I was given during onboarding. I see an error that says "this key is invalid"...

In this case, what should we do? Also, how does this factor into our conversation and commitment to remove keys from local storage?

Regarding Torus and derivation paths, what does this mean for how we implement Torus for implicit account creation? If I create Account 1 with Email 1, then attempt to create another account (Account 2) using the same Torus email, how can we accommodate this? It's unclear to me currently if this is possible without some way for Torus to create a multiple implicit accounts derived from the same private key...

cc @Patrick1904