Grin HD wallet & One time use addresses RFC

[Anynomous]

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:

[Withdrewed] Request for Funding @davidtavarez: One-time use Slatepack addresses for Wallet (RFC and Grin++ Implementation)

The way I see it you are a builder and you are good at it. So that is what you should be doing since that is what you enjoy and there is indeed a lot to do on your roadmap. I think it would be best if I and others (e.g. @oryhp @vegycslol, advice on how to deal with security) pick up the proposal and extend it by thinking of how a Grin HD wallet and one time use addresses should look like and work towards and RFC. I do not think the RFC is something you should spend to much time on although you…

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

On-chain bookkeeping

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.

Address

m’/44’/592’/1’/0

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:

0:Not-yet-used
1:Permanent
2:disposable
3:closed-but-not-empty
4:closed

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.

[oryhp]

@Anynomous

I would like to invite @oryhp

Sorry for the late reply. I unfortunately have no understanding of derivations today so I’m not really of much help on this topic (I could learn, but this would be yet another thing on my already long list). Eventually I might get to these topics but I have a few others on my mind right now - transacting is something I’d want to invest time in. But I’ll definitely take the time to try to review if an RFC appears.

[Anynomous]

Thx @oryhp after collecting the initial feedback via the forum I will use the template on github to push it as an official RFC.
Also non derivation related feedback is welcome.
E.g. for people who have payment processors, what is a logical number after which to close an account, 60, 1000?
And for wallet devs, is the minimal on-chain metadata workable for you? The wallet should scan only for one address/key for permanent channels, is this also sufficient for one-time use addresses for a web-shop? For temporary addresses, should the wallet scan for all addresses in that chain each time, or only the latest one that is open. In case of multiple, which amount of keys to scan for would work from a memory point of view? Such kind of questions I can absolutely not answer myself.

Also I am still wondering how manageable it is to have multiple slate-pack addresses online simultaneous, is this even technically possible at al? @davidtavarez @davidtavarez @antioch.

[david]

@Anynomous

Also I am still wondering how manageable it is to have multiple slate-pack addresses online simultaneous, is this even technically possible at al?

Yes, though there is a privacy issue we must be aware of. If we activate all of our addresses at login, then if someone just monitors a list of active slatepack addresses, they may find some that become accessible at the same time, which can link them to a single identity. So it’s probably better to limit how many are online at any one time.

[Anynomous]

After the discussion on payment processors:

Developing a Self-hosted Grin payment processor Wordpress Plugin

In that case the shop owner receives the transaction and still would require to sign the transaction manually using his ledger, e.g. do this once in the weekend, that should be manageable. I think in pracitice this will not be an hurdle since most people do have exchange wallets any-how, and they do accept the manageable risks that come with it. With Grin it is not that different, e.g. both traditional crypto and Grin need to be connected to see if a transaction worked out. So the main diff…

I think we need expand expand the RFC proposal above to discuss

1. HD wallet derivation + one-time use slate-pack addresses, with
2. automatic transactions to cold storage using pre-signed transactions for a predetermined amount.

In the end discussing one piece of technology is not so interesting as long as the complete picture is not there. In this case the target is to allow using wallets for payment processors which require one-time use slate-pack addresses, as well as a secure way to transfer incoming funds to a second (cold-)wallet.

Therefore the discussions in this forum post should not be limited to one specific technology, but more what the user experience would be that we would like to see for a payment processor/hd-wallets.
Whatever technologies are needed to reach the desired user experience, should be discussed holistically and not independently.

[grn]

if someone just monitors a list of active slatepack addresses, they may find some that become accessible at the same time, which can link them to a single identity.

Do the actual addresses need to be stored on the chain. Wouldn’t it be possible (and more space-efficient) to store only (salted) hashes in a probabilistic data structure, such as a Bloom filter? I think the worst case outcome would be a false positive for “has this address been used?” and the wallet could not use this address anymore. With only hashes in a Bloom filter, the actual addresses could not be linked to any identity, even if the data structure itself is public.

Bloom filter

[Anynomous]

Actually, the slatepack adresses would only be linkable because they come online at the same time on tor. So there is no on-chain address, it is still pure mimble wimble.

In case of one-time-use slatepack addresses, this would not be much of an issue, since after each transaction a new slatepack address is generated.
For permanent accounts it is however an issue since these are as the word says permanent, so likability there is a privacy leak. One option would be to by default only have permanent address online at a time unless the user enables the address or changes this default behavior knowing the risk.

[grn]

I see, so the issue is if a user has multiple permanent addresses that come online at the same time.
Having the ability to manually enable them individually when a user intends to use them, seems like the best approach to me.