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

tl;dr

On April 1st my previous funding request expired. In order to advance the Post 5.0.0 wish list I would like to tackle the One-time use Slatepack addresses for Wallet and implement this in Grin++. This implementation requires a RFC.

What do I want to achieve?

The SlatepackAddress is a shareable bech32 encoded ed25519 public key that can be used both to route synchronous transactions and to encrypt asynchronous transactions. We can use Grin HD wallets to generate deterministic ed25519 public keys and therefore Grin addresses. Addresses are being generated using keychain paths.

I will bring the possibility for the users to be able to use one-time Slatepack addresses.

Why I want to do that?

One-time addresses is a tool to protect users privacy and are very common in a large variety of cryptocurrencies. Grin should definitely give this option to the users. One-time addresses are not the same as addresses from different accounts, this One-time addresses are tied to an specific account. Users can use one-time address for each account.

Time Estimations/Plan

In this situation it would be hard to estimate time. I will considered this as finished when the RFC gets approved. This process could take x amount of time that I am not aware of. The plan is to have a working implementation on Grin++ of the RFC. This will help us to see this working and polish the UX. The implementation of this RFC on grin-wallet will depend on the Rust team priorities.

Anyways, if one wants to be pessimistic I would say that in 2 months this should be merged into the Grin++ master branch. But since Grin have this 2-weeks cycle for the Developers meetings, I might be shooting myself in a foot by giving an estimation because I can’t say when the RFC will be approved and I can’t predict the potential suggestions :sweat_smile:.

Funds requested

I am requesting 10.000 EUR equivalent in BTC. I will place a PR for the RFC and also, I will have this feature released on Grin++ Desktop.

Logs

15 Likes

if it’s a one-time address which always uses a new tor address then if i have 100 active transactions you will need to have 100 tor listeners? What if instead you would have eg. X addresses per tor address but you would filter them out based on the nonce that you put in that address (eg. nonces would be from 1 to X)? It might also be possible to only have one tor address, but maybe that’s not preferable. What i’m thinking about is the async non-autoreceive tor support

1 Like

I fully support researching this direction :+1: The reason I say researching is because I believe this is much more of a research problem than an implementation one. My understanding is that the ed25519 public key is the identity which is used for payment proofs. If this key gets changed per transaction, then the existing payment proofs no longer work because you have ephemeral (one-time) keys which are no longer identities and would need to be signed by an actual identity outside of this context. It is definitely worth researching imo (I might also be wrong about the above). I remember @joltz mentioned one time addresses when we were discussing possible improvements so perhaps he has also something to add here.

P.S. I really believe we should first get the RFC to accepted and only then implement things. Similarly like fix-fees RFC right now where we have a blocked merge and are waiting for the acceptance.

Edit: oops, I just remembered I had a conversation about this with @david and he suggested having a suffix in grin address which changes. I believe this form has no issues with the problem I mentioned.

2 Likes

In support of this funding.
Just to improve my understanding, is this is different from adding another level of derivation to the keys you use for each address, e.g. going from m/44’/0’/0’/c to m/44’/0’/0’/c/i?

What is the current situation for Grin++ and grin-wallet. Does Grin uses a new key as blinding factor for each transaction, or just one key for all transactions?
One reason why I want to understand this better is because I think this also is related to on one of the community projects ideas, creating an Airdrop workflow.

So e.g. generating one time use keys to which you send some Grin for an airdrop. Users can self spend, send the transaction to their own wallet upon scanning. After e.g. 1 year, you reclaim any unclaimed airdrops from your airdrop account.
Alternatively special airdrop seed phrases could be used, e.g. 12 word seed phrases. Only in this case it might be harder to manage and reclaim unclaimed airdrops, unless we use something like BIP84

This is a bit off-topic since no new slatepack addresses are needed to self spend an airdrop, but it does relate much to the derivation sheme used by the wallet. Best to consider all future uses.

1 Like

Maybe relevant.
Attacking Deterministic Signature Schemes using Fault Attacks
https://eprint.iacr.org/2017/1014.pdf

1 Like