Wallet generation enhancements

[jenlij]

Currently, we have the following flow:

• A CLI client generates public keys based on mnemonic
• It posts the public keys to the storjscan with a custom text (today: name + derivation path)
• When it's requested, it reserves one more public key / address
• Keys are generated offline in batches, so someone must generate and upload new keys to storjscan if more are needed

A couple of options for generating keys on demand:

1. If there is no available key in the database, create one on-demand:

• Check if the table has a key with custom text name + seed
• Check the last used derivation key and bump it
• Make sure that the seed address is flagged as claimed

Note: It might be better to use two db columns for name and derivation path in this case

2. Extended public key (xpub)

• hand out 1 xPub per satellite. So the first satellite would use m/44'/60'/0'/0/0 the second satellite m/44'/60'/0'/1/0 and so on.
• The satellite itself doesn't need to know the derivation path because the xPub is the replacement for that. The satellite only needs to derive subkeys from the xPub. A simple counter will do that job. For the first satellite the first address wout be m/44'/60'/0'/0/0 and the second address m/44'/60'/0'/0/1 for the second satellite it is m/44'/60'/0'/1/0 and m/44'/60'/0'/1/1
• Implementation is simple because we can use the same code for all satellites and because they start with different xPubs they still generate different addresses.

Note: Since satellites are independent, the derivation path can be the same for different satellite, if different mnemonic is used

https://storj.slack.com/archives/C02HDN77485/p1653559481789419

[dlamarmorgan]

One idea for how we may be able to prevent spam bots from claiming wallet addresses is to require certain "milestones" be hit by the user before they can claim a new wallet. Some examples are, account must have a project with both uploaded and downloaded traffic, or must have a balance due before you can add a wallet payment method.

[littleskunk]

There is no need to prevent spam bots. Let's say we just give every user a numeric ID. With an xPub we can generate the wallet for each user faster than the user can signup for a new account. It works like an unlimited list with pre generated addresses and we just pick the next one in the list.

[dlamarmorgan]

Should we care about the DB table size though? Each new spam account would end up with a row in our table to map from user to wallet address.