In #955 we introduced a new registration flow which uses BIP-32 account derivation to
create newly registered Entropy accounts.
Simply, it works by deriving new accounts using the following path:
m/0/{registration_count}.
While this is a nice and simple solution, it comes with some problems:
The counter used is not guaranteed to be monotonic
The derivation path is predictable and has no additional entropy
(1) is addressed in a bit of a roundabout way, in that the CountedStorageMap we use is
only appended to, and entries are never removed. However, we have no way to enforce this,
and future developers might break this.
(2) can be addressed by making the derivation path use something like the registering
user's AccountId as a form of additional entropy.
My first instinct here is to use something like path = hash(account_id) ++ counter, but
we may want to think about this more to see what other options we come up with.
In #955 we introduced a new registration flow which uses BIP-32 account derivation to create newly registered Entropy accounts.
Simply, it works by deriving new accounts using the following path:
m/0/{registration_count}
.While this is a nice and simple solution, it comes with some problems:
(1) is addressed in a bit of a roundabout way, in that the
CountedStorageMap
we use is only appended to, and entries are never removed. However, we have no way to enforce this, and future developers might break this.(2) can be addressed by making the derivation path use something like the registering user's
AccountId
as a form of additional entropy.My first instinct here is to use something like
path = hash(account_id) ++ counter
, but we may want to think about this more to see what other options we come up with.