We need to have some temporary wallet system for that. For example derived under a special branch of the senders main wallet. When importing, a temp wallet needs to be created and used to send to main wallet. The temp wallet can be deleted/destroyed after for example 48 hours of blocks have passed.
For the sender there needs to be some memory of the index of temp wallets used to created vouchers to avoid reuse.
2 Likes
If I understand it right, these are the steps:
- Alice sends funds from her wallet
Ato ephemeral walletE - Alice shares the seed words for
Ewith Bob - Bob imports
Eand scans outputs to find outputs owned byE - Bob self-spends from
Eto his own walletB
This makes 2 on-chain transactions (step 1. and 4.) to create one real transaction. As tromp mentioned, it can’t have a payment proof because you can’t prove who moved the coins from E because both know the secret.
I think we can achieve a similar thing with a single transaction Grin donations · GitHub . I’m not sure if we want to have such options supported though because it introduces a new “tx type” for something which is an edge-case. One of the great benefits of Grin (imo) is that we have a single tx type that is very flexible and hopefully it will become even more in the future by having safe >2 party txs.
1 Like
It took some time for me realize, but I realize the importance of keeping the consensus and transaction simple. Like you I hope we can go to a single transaction type (beyond the SRS and RSR discussions). Therefore I prefer this ‘Grin voucher’ option, since it is basically not a new transaction type, just a way to share a mnemonic with all the benefits a new transaction type would have. A voucher system even hardly requires changes in the wallet software(s) except for multi wallet support. The trickiest part is probably having the ephemeral wallet and the real wallet open at the same time since both are used for signing consecutively.
I did not mention it above, but optionally the message could be armored/encrypted for a specific receiver when specifying the address to send to In that case you basically get a 2 step transaction with full privacy, especially if we would move towards single size slate-pack messages.
From a software point of view I think creating such voucher system should be relatively straight forward while not require any changes to the transactions themselves, which is preferably IMO.
The only case where it has some disadvantages is in the case of a wallet restore since the sender lost track of the index of the ephemeral wallets used for creating vouchers. Only a minor issue if you ask me.
Your ideas are good, in the future I hope you will take part in what we offer.