BIP44 derivation mode should stop at first empty account

[gre]

per bip44 spec, the derivation of accounts should stop at first account without transaction:

Software should prevent a creation of an account if a previous account does not have a transaction history (meaning none of its addresses have been used before).

do you plan to support this? I know it can be challenging in that it requires you to asynchronously fetch if a given address have transactions.

The potential problem when not implementing this however is that we'll end up with accounts that are not discovered by Ledger Live (or any other application that strictly follow bip44) if people start selecting accounts without respecting the order (which happened a lot with MEW and that's why we forced to scan at least 10 accounts in advance).

[danfinlay]

We’d love to implement parts of the spec that make life easier for other clients.

We actually have a basic version of this implemented behind a feature flag, but it depends on hitting etherscan for the transaction history, a centralized component that would not currently be configurable, since there is no decentralized API standard for querying account histories.

In addition to centralization concerns, one point really stands out as a big obstacle to capturing the spirit of that part of the spec:

There is no easy way in Ethereum to look at all transactions that are relevant to a given account. While Bitcoin can simply look at UTXO owners, since there is only one coin type, Ethereum accounts can “receive” a variety of virtual goods, from non-fungible tokens to domain names, and these goods are all encoded in their own formats, in their own smart contracts, and so even with a full node indexing transactions related to every account, there is no universal way of capturing every “incoming” transaction related to an account for every current and future asset type.

It is possible this could be the subject of a future standard: Maybe a certain Event could be associated with any transfer type (we could maybe just use the Transfer() event as used by tokens and NFTs today).

We’re open to implementing a good solution in the future, so we aren’t declaring an absolute stance on this, but we would want to make sure we had a path paved that made life easy & pleasant for our users.

Without a clear path like that, it might be simpler for Ledger Live to simply ignore that part of the BIP44 spec when creating Ethereum accounts.