Hello everyone, I would like to propose a straightforward idea for a two-step transfer process for grin. I would appreciate your feedback on this concept.
What if we could simplify the transfer process by implementing a two-step method at the wallet level? Instead of one transaction, we would initiate two transactions. Here’s an example: If Alice wants to send grin to Bob, she could create a temporary wallet with a new private key and transfer grin there with just one click on her wallet. As the owner of both wallets, she could perform all three steps (creating the slatepack, receiving and finalizing) in a single step. She can then get the temporary private key and send it to Bob with third party messenger, Bob puts the key to the wallet and with single click moves all grin to his wallet.
The temporary private key could be prefixed with 5GRIN_, so Bob would know how much grin Alice is sending and the wallet can know what to do with that. Additionally, the private key could be encrypted.
Here are some advantages to this two-step transfer method:
Transferring process becomes very simple.
As far as I understand we can solve the likability problem. Temporary wallet is getting all spent outputs so these transactions becomes intermediate and will be removed from the blockchain. Also even with 2 transactions instead of 1 the blockchain will stay compact.
However, there are also some downsides:
The receiver would have to pay a fee.
There is an increased risk of a Man-In-the-Middle Attack.
Giving someone your output blinding factor(s) (which is what you’re proposing essentially) is not so much a transfer as it’s changing an output into a 1-of-2 one; Alice and Bob can both spend it.
Worse still, it can lead to disputes when one of them spends the output while claiming that the other one did. There’s no way to make this work with payment proofs.
You can’t know if the Bob has received the money, only Bob knows (Alice knows only that she didn’t take it but can’t be sure whether Bob or someone else took it). You could encrypt the private key with Bob’s public key to avoid man in the middle attacks, but the real issue here is that you probably can’t create a payment proof for such method
I do believe they will be used at some point, they have limited use cases. They don’t require any protocol change so they can already be done manually today and a wallet app could build in automated creation/redemption on the client side.
Tipping would be an example of a non obligatory payment where you could leave a voucher. Sure you could revoke it, but that would just negate the point of leaving it and make you look rude.
I proposed this idea a while back, caling it “Grin vouchers”. You can find the reasoning and use cases here. Yes, it can be used if someone specifically wants 2 steps but it is by no means ment to replace normal three step transactions.
I see its use mostly for air-drop, vouchers, top-up cards etc. I do think “the Grin vouchers” idea has merrits as a “add on” to normal grin.
I think mimble-wimble.py would be a great place to develop and test ‘fun-features’ such as grin vouchers. I can totally see myself transfer funds from my normal wallet to a less secure python wallet, where I create temp wallets/vouchers to sell or give away as air-drops. Since it is python, developing somethink like this can be done by me or others who can code but are not at the level of "core"developers.
Yes, I see it as additional features in the wallet like Ironbelly etc. Of course it’s less secure, but I’m sure a lot of people will use it to transact with someone they can trust and also to transfer a small amount of grin.
There is no way to know if Bob received the money in any way if Bob says I didn’t receive anything, there is no way to prove it because grin has no addresses. We can only prove that someone received, and who was, no one knows. Of course, Alice can provide as evidence the correspondence between them and show slatepacks, but this will be evidence from a third party, and not on chain, we can do the same with the proposed method.
In SRS and RSR (well in RSR it isn’t yet implemented) the sender has payment proof of payment. This payment proof includes sender, receiver, amount and in the future probably also memo which will allow us to commit to the content of the tx (eg. sender bought an apple from the receiver). So technically, this payment proof is a 100% mathematical proof which could be used in court (in the future, when people might use their actual ID keys). In your proposed solution you unfortunately can’t have payment proofs
theoretically Bob could announce his ed25519 public key with which current payment proofs are signed or in the future this signing key could also be his official identity public key, but that’s in the future
