doc: Scaling Use Cases #30
Conversation
msbrogli
force-pushed
the
doc/scaling-use-cases
branch
2 times, most recently
from
595ab99
to
b47907d
Compare
msbrogli
force-pushed
the
doc/scaling-use-cases
branch
from
b47907d
to
1f5687f
Compare
|
|
||
| This approach does not scale easily because the global wallet will have to keep track of more and more addresses over time. The more users, the more addresses. The more addresses, the more memory is required. | ||
|
|
||
| Another challenge is to scan the transactions of the global wallet. The most common stop criteria for the scanner is the GAP Limit, which stops the scanner when `N` addresses in a row are empty. An address is empty when it has no transactions. |
There was a problem hiding this comment.
Given that it's a generic doc for use cases, I think we can explain when the gap limit problem can happen. I though about starting this paragraph like this:
Depending on the moment that the use case associates a new address to a user, we may face another challenge to know when to stop scanning the wallet address. E.g. an exchange associates the address to a user as soon as the user requests it but he might never send a transaction to it, on the other hand, some use cases can wait until the moment the user needs to send its first transaction before associating an address to him. In this scenario, no addresses would be unused.
| - Xpub wallets have an xpub, and the addresses are scanned using the GAP Limit stop criteria. | ||
|
|
||
| In this case, it is easier to use xpub wallets and ensure that the deposits meets the requirements of the GAP Limit. | ||
|
|
There was a problem hiding this comment.
We could add a section explaining a bit of how HD Wallets work (BIP32 and BIP44)
|
|
||
| Such pool would consume resources according to the number of concurrent users (instead of total users). It can easily scale up through the addition of more servers to the pool. | ||
|
|
||
| ## Full-length Wallet Service |
There was a problem hiding this comment.
I think we should add a note explaining that this option is not currently available as it is being tested internally
|
|
||
| This case differs from the previous ones because there will be multiple wallets running. | ||
|
|
||
| First of all, there are multiple ways to associate a wallet with a user. To illustrate, some ways are: (i) one seed per user, (ii) one global seed with one passphrase per user, or (iii) one global seed with one derivation path per user. |
There was a problem hiding this comment.
Isn't option (iii) the same as the last section (Global Wallet with Derivation Paths)?
Rendered