I want to create this topic to further discuss the details of the “One time use addresses” idea created by @davidtavarez. Basically this idea need to be extended to create a standard on how Grin HD (hierarchical deterministic wallets) should function:
We could assign it a GIPXX number (e.g. GIP44), just like how BIP (Bitcoin Improvement Proposals) work.
With Grin HD wallets here are additional concerns that should be taken into account:
1) security 2) wallet performance 3) blockchain bloat 4) simplicity - since that is part of Grin’s motto and since wallet developers should not have to deal with unnecessary complexity.
For this reason, I would like to invite @oryhp, @vegycslol and anyone else to work towards a solution that is both user friendly, developer friendly and secure. Of-course @davidtavarez, @david and @antioch 's feedback are also highly appreciated since the proposal should be workable for wallet developers.
The basis is to work with a BIP44 HD derivation structure (m/44’/0’/a’/c/i). In this case the coin number c’ = 592 for Grin and the account number is the derivation branch for a specific purpose/account of the users choosing such as a permanent address or an account for one-time use addresses e.g. for payment processing. To give an example of a wallet with one account for a permanent address and an account for disposable one-time use addresses:
web_shop0 Address m/44’/592’/1’/0 | temp | Bookkeeping address for the disposable account
web_shop1 Address m/44’/592’/1’/1 | temp| disposable address
web_shop2 Address m/44’/592’/1’/2 | temp| disposable address
grinmint_mining0 Address m/44’/592’/1’/0 | permanent | Bookkeeping address stating this branch is a permanent address
grinmint_mining1 Address m/44’/592’/2 |permanent | address for receiving transactions
I think it interesting to discuss adding some “minimal on chain bookkeeping” to:
1) improve security 2) to avoid blockchain bloat and 3) keep the wallet performant (by minimizing the number of keys that the blockchain needs to be scanned for).
I included these bookkeeping addresses in the example above which can be used to indicate the “status” of an account and its use.
It would be best to use the first address at the lowest derivation level to contain the status of that specific account. Below a rough draft of this “on-chain metadata” which is only visible to the wallet owner. The cost of this online bookkeeping are very low and only include the transaction fee when opening a branch or changing the status of that account branch. The online bookkeeping could even be an opt-in solution for both users and wallet developers, similar to a soft-fork, since only very specific values have meaning to the wallet. For security it would be best though that all wallet software would avoid the first address of each account to respect its use for online bookkeeping by some wallet software’s.
Value in mili-grin send to the first account (branch) address for on-chain bookkeeping. The wallet will interpret the value on this first address of account to decide what to do both for the wallet in use ass well as upon a wallet recovery from the mnemonic seed phrase:
In this way when regenerating the wallet while knowing which accounts of the HD wallet to scan as well as which addresses not to reuse as explained below:
- 0 : Free to be used. The account can be used for any permanent or disposable keys
- 1 : Permanent, the wallet will scan with a single derived private-key since it is a permanent account and the associated address can be reused after recovery from a mnemonic seed.
- 2 : Disposable, some addresses of this account might have been used. To avoid reusing addresses after a wallet recovery, the branch will be scanned and all funds will be transferred to a permanent address. The account will be closed by changing the status to 4 (by sending an additional 1 mili-grin the first derived address.
- 3 : This status is for if the wallet is still in use, meaning the temporary funds are there no new addresses are generated for this channel, nor is the branched scanned by the wallet unless manually asked for refresh by the user. this will improve performance since only active in use accounts will be scanned for
- 4 : The account is closed and empty, meaning the wallet will upon recovery completely ignore the branch. The wallet will not scan the chain for any derived keys and will discourage or block the user from re-using the branch for security reasons.
By limiting the maximum derivation dept of one-time use addresses (e.g. payment processing) to for example only 60 per account (whatever number we decide on), the wallet will only have to scan for this number of keys in any one-time use key branch keeping the wallet performant. The maximum dept will also avoid on chain-bloat by HD wallets, by stimulating emptying one-time use wallet accounts after reaching the maximum dept of 60 transactions.
Let me know what can be improved so we can work towards a RFC and hopefully an implementation.
This RFC proposal is an important step to add functionality for normal users by allowing one-time use addresses as well as for payment processors that might want to have one-time use addresses.