-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Scaling Use Cases #30
base: master
Are you sure you want to change the base?
Conversation
595ab99
to
b47907d
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't option (iii) the same as the last section (Global Wallet with Derivation Paths)?
Rendered