Please could someone comment on whether this is technically possible in Grin (now or in the future):
I need to pay 3 different people, and I’m communicating asynchronously with them all. I am expecting that some of those people may take several hours or days to respond, since they might have their computer turned off or wallet not running.
I only have one output in my wallet to begin with.
Can I send a transaction slate to all 3 of them, wait for the first person to respond, and then immediately finalize a transaction that only pays that first person and immediately sends me the change?
Now, they’re not holding me up from using the change from that finalized transaction to pay the next person that responds.
After the slates have been sent out, can I later decide to either: 1. wait an hour for all 3 to respond and send the funds out using a single transaction, or 2. send payments out to each person individually as soon as each of them responds, and each time use the change output to pay the next person that sends a response to me.
A more general way of asking this question is: In an asynchronous scenario, are there any cases where Grin could make me wait several hours/days before making my next transaction, because I’ve already initiated a first transaction and need to wait for that change in order to perform the subsequent transaction?
Yes; you can send out 3 slates, and finalize the first one that comes back. Confirming that tx will invalidate the other 2 slates, as their input is no longer unspent. Then you can send out 2 new slates to replace the (soon-to-be) obsolete ones.
One option would be to split the output into three outputs within your wallet, before sending the slates. Then each slate will not conflict with the others.
Kind of obvious but you could send a transaction to yourself to split the output into 4 different outputs, then use the 3 of them to transact with those people you wish to transact. Obviously you need to pay a fee for the self-send but at least you are not tying up all of your money into those three transactions. I expect wallets with custom utxo splitting strategies will be able to offer a nice UX around that.
EDIT:
For slow transactions that involve passing slates back and forth, I don’t see another way out of avoiding locking up all of your money other than segregating those outputs from the rest of your funds.
Thanks for the reply. I’m a bit rusty on my understanding of Grin - I thought that the purpose of the response from the recipient was only so that the recipient could choose the blinding factor of the received output and construct the range proof such that it allowed the recipient to restore their wallet from seed by rewinding the range proof.
Is there a reason that it’s not possible to use those responses from the intended recipient to create that same output for the recipient, but as part of a different transaction? The recipient could detect the received output either by scanning the blockchain or by notification from the sender of a revised transaction hash.
I’m assuming the sender can do something clever with the new change output attached to the revised transaction, which would ensure that the kernel excess would still be the same (offset the new change output blinding factor by the difference between the blinding factors of the old input(s) being spent and the new input(s) being spent).
In addition to a commitment to the blinding factor, and a rangeproof, the recipient response also contains a commitment to a nonce, and their partial signature.
Excellent question!
The recipient’s partial signature depends on the signature challenge hash (the e in s = k + e * x), which in turn depends on the sender’s blinding factors (of both the input and change), and so would appear to be obsoleted by having the sender spend their input elsewhere.
But it actually only depends on the difference between change blinding factor and input blinding factor, so it looks like the sender could use the slate response after all, by choosing a new change blinding factor appropriately.
That would seem to solve the problem of doing a payout to multiple recipients. You’d perhaps wait 60 seconds to see which wallets respond immediately, and then finalize those transactions immediately. The stragglers would then be paid out whenever they eventually respond. You could do this even starting with a single output in your wallet, and there would be no need to spam the blockchain in advance by exploding the output into lots of little outputs.
Not sure if this is a dumb question or not - is it currently/theoretically possible to send funds to more than one recipient in the same transaction?
@knaccc I’m part of vault713, we’re behind grinbox and wallet713. We have built a payment processor, cashier713, that’s tailored to businesses that need to handle large volumes of outbound grin transactions, such as mining pools and exchanges. It solves the problem you describe above, paying to multiple recipients in a single transaction, using a single output (or more), and it batches the payments together and runs scheduled payment cycles. State is handled by a Postgres backend. The product is production-grade and handles loads well. For more info or a demo, hit me up on DM here or on keybase (@lehnberg).