The easiest example would be an exchange that manages funds for multiple people. For each customer you have a separate account, derived from the same master seed.
In theory it could even be semi non custodial, meaning each person can backup their own account master key and derive its sub addresses. Similarly one could create a PubKey to show funds for a single account/customer.
The example from @yasabi is also common, you only want a single node and wallet, but have separate accounts for private and business.
Regarding what this protects against, not really adding protection, just compartmentalizing funds in a way that resembles the real world, so on account/user/use-case level.
Running separate wallets does add a lot more privacy but has the downside that you only can have one wallet/tor address listening at the same time.
Isn’t this a classic case of over-engineering then? You could simply tag what the transaction was for. Or have the wallet do it for you. No need for a whole extra key that gets derived. And your example with the exchange is kinda nuts, no? An exchange would derive a hundred thousand subkeys? Maybe even a million subkeys for their users? Huh?
If someone sat down and gave this user story, they would not arrive at a solution like this. So I’m thinking the user story was something different than just “folders for transactions”.
Anyway, the reason I ask is because I wonder if the UI of Grim could guide the user into the best practice of how to use it. But it seems like there is still some confusion on why you would want to use it so maybe it can’t be improved upon for now
It will be FAQ with examples for sure.
Imagine you have physical cards at your wallet.
Here you can change personalities from single seed phrase, cause we can always generate public key like grin… address and use it for some activities, use-case also will be created, have a patience
It’s basic functionality also for hardware wallets, users will import their accounts from any BIP32 wallets without problems.
To be sure, I’m not saying it’s only your responsibility. Because all you’re doing is implementing existing grin features.
It should be in Grin documentation generally. I’ve just never seen it until I saw it in Grim.
I’m actually kind of mad that people implemented this though. Simply tagging transactions as being for this or that would be the more sensible approach. Because you dont need multiple sub-accounts when there are no accounts on the blockchain itself. Someone that was used to Monero thought grin needed a Monero feature I guess.
Accounts could be thought of as somewhat similar to different bank accounts under the same name. Each account acts as a separate wallet, but they are all derived from the same master seed. The default account is created when you initialize the wallet.
So you can create a checking and savings account. Of course both accounts would use the same password, seed phrase and even multisig. So it wouldn’t help you in terms of increased security for the savings account.
So you can create a personal and business account. Of course there are no addresses on the blockchain, so it doesn’t give you any extra isolation / privacy by doing so. All you’re actually doing is adding complexity to your wallet in order to tag which transactions are personal and which are business on a superficial level.
I must be missing something about this. Does it provide some other benefit that I’m not realizing? Can you send money from the personal to the business account for free? If it costs money to send between your accounts, then it’s yet another reason it’s a bad use case.
Security should be the same for all wallets/accounts, check SeedQR and how SeedSigner is using it, I am ordering parts from it now to integrate it with Grim too, so everybody can build hardware wallet for Grin at home! Also it will be offline wallet functionality integrated inside the app itself. Moreover we can build our own OS with minimal requirements for kernel from scratch in Rust, good thing we have a lot ツ
@trab TL;DR Having multiple accounts is basically free with no cost in complexity order or speed and has good historic reasons to exist.
This is based on BIP32 which is existing since 2012 and uses account for good reasons [READ THIS]. Both for consistency and compatibility reasons BIP32 should be used for wallets. Most important to realize is that a) there is no additional cost, deriving a key for account 1 or account 2 or account n, it is equally fast b) For privacy one would like to keep outputs separated per user/use-case/account, it like basic privacy to use multiple accounts very similar to why one would use multiple wallets. I mentioned it before briefly, but since derivation at each account level is hardened (an EC step is build in), it means that keys from an account, both PubKey and PrivKey can never leak information about other accounts. So it is like a useful firewall to protect users on the account level. E.g. A user can get the Privkey at account level and derive al its own sub-keys and for example use a light client to scan for transactions belonging to its account without ever knowing about other accounts. Grin does not strictly need it right now, multiple wallets would also do the trick, but for advanced users who would for example build their own exchange (Easy grin), I am quite certain they are using the accounts.
@ardocrat Talking about Seed|QR. Would you be interested in implementing a wallet Sweep function at some point?
I am asking since it is needed for this “Grin vouchers” idea I had for some years:
Basically a wallet seed as QR that one can scan from a gift-card, top-up card, or directly from a mnemonic to allow people to send funds in one interaction (easy but insecure since no transaction proofs are created).
It is great you implemented everything freely so far, but if some funding would be appreciated, for example bounties for certain functionalities, let us know.
That would be tricky since Rust does not have a compiler for Windows XP, perhaps it can be done when building on another machine that has Linux or Windows XP.
Another way might be via virtualization, e.g. docker.
Maybe our @ardocrat knows if it is possible to compile for XP.
