One of the often mentioned problems with grin is impossibility of securely producing transaction while two parties are not online simultaneously. It is possible to use messenger applications to exchange slatepacks but that requires to partially reveal ones identity. Inspired by this forum post I had an idea to draft a protocol allowing to outsource the work of online listener in exchange for a fee paid in grin.
I describe the idea in the repository linked below. I would really appreciate if you helped review it and contributed. I will accept pull requests to this file if there are any and welcome all the feedback.
Sorry, I mixed up Alice and Bob. So Bob comes online and finds Alice. The multi-sig tx has already been opened. How does Carol get told that she will not receive 0.1ć, or will she?
If Alice and Bob find each other without Carolās help they can form a transaction again completely omitting Carol. The inputs involved in the transactions become spent thus making whatever Carol had completely invalid. Carol can find out about it by checking new blocks.
It might be unfair for Carol, but it also emphasizes that Carolās role here is to assist Alice and Bob and not vice-versa.
Edit:
The fact that Carol needs to listen to new blocks partially forces Carol to run own node (as community nodes might not be responsive enough to run such service), as a side-effect improving ć network security by providing more nodes that in addition generate some profits to their owners.
The tx amount from Alice to Bob is revealed to Carol though (?) if she is a signer of the tx, so Carol could potentially leak receiver, sender and amount, right?
I donāt think Carol know the amount apart from own fee of 0.1ć. Neither the new outputs neither the input being spend. My argument for that is Carol only needs to pick a blinding factor for her new output, the rest of the signature is none of her concern.
the modified flow would consist of three actors: sender (Alice), receiver (Bob) and intermediary (Carol)
Sender commits to amount, fee, and a public nonce, public excess. It could also commit to tx offset, inputs, change output, and probably others. Transaction gets send to the intermediary.
The intermediary adds own fee output & rangeproof, and commits to their public nonce and excess. It then updates the total kernel commitment, and signs for their fraction of the kernel. Transaction waits until the receiver gets online and picks it up.
The receiver adds their output & rangeproof, and commits to their public nonce and excess. It then updates the total kernel commitment, and signs for their fraction of the kernel. Transaction gets sent back to the intermediary and waits there to get picked up by the sender.
The sender adds their part of the signature, aggregates the 3 partial signatures, and builds the final transaction.
From my understanding, this is a 3 party multisig between Alice, Bob and Carol on the same message. I think the intermediary Carol canāt sign at step2 because she doesnāt know the public excess and nonce of the receiver. So it would only sign when it gets it back from Bob so the flow of information would in this case be:
Denote Ae, Ar as Aliceās public excess and nonce, Be, Br as Bobās and Ce, Cr as Carolās.
Alice sends Ae, Ar to Carol
Carol sends Ce, Cr to Bob
Bob adds all the excess and nonce, adds their output and sends back to Carol with his partial sig
Carol adds her output with fees and adds her partial sig and sends to Alice
This could be much simplified if you design the service to be provided by a mining pool as Carol. Then she can just check that an extra fee is paid.
The question is how to ensure that no other miningpool can get this extra fee. Hereās one idea that may or may not work:
If Carol hides the receiver offset from the sender, then the latter cannot publish the final tx themselves, but has to hand it back to Carol who can apply the receiver offset before mining it.
I think I see what you mean. Carol receives a commitment of the form
A = b1*G + a1*H
and Bob is expected to form
B = b2*G + a2*H
in a way that
A - B = (b1-b2)*G + a3*H
where a3 should be exactly the fee that Carol is supposed to receive. Carol can form her own commitment in a way to make the part generated by H vanish.
To my understanding, the purpose of the last step was for the sender to add own partial signature of the final offset and aggregate all the partial signatures together.
Can Alice provide her final partial signature without knowing Bobās offset?
If (1) is true, then why getting back to Alice in the last step, couldnāt she simply produce her partial signature while submitting the transaction to Carol?
Yes, because offset is not in the challenge e afaik.
So the challenge for the signature will in this case be
e = H(M | Ae + Be + Ce | Ar + Br + Cr)
The full signature they will produce will be for the following equation
e*(Ae + Be + Ce) + (Ar + Br + Cr)
The part Alice needs to contribute with her partial signature is
e*Ae + Ar
She knows Ae and Ar variables, but she canāt know e because if you revisit how we compute e youāll see that she needs to know also the public excess and nonces of other participants (Be Ce Br Cr). So basically before anyone starts signing, they need to add up their public excess and nonces so that they can compute the challenge e which is required for signing.
P.S. I donāt know whether this 3/3 scheme has the same security, maybe it does, but weād probably need to prove this scales and no funny business can happen through collusion of multiple parties.
renzokukenās questions were about my suggested simplification in which there is no Carol output and no Carol excess. Instead Carol is a mining pool that wants to be paid with a higher than minimum fee. If Bobās offset is communicated to Carol but not to Alice, then Carol (and only Carol) can mine the final tx.
Interesting. This also means that the transaction is never seen in the mempool and mining pools act as not only storage of slates but also as coinjoin servers if they have enough traffic.
In the approach proposed by me and @oryhp Carol would manage communication with Bob and eventually send it back to Alice for finalizing. Carol would charge a small fee for being online for both parties. Protocol is trustless.
In the approach proposed by @tromp Carol would manage communication with Bob but would no longer need to communicate back with Alice. Would still charge a fee and each of participants would communicate with Carol only once.
If Carol goes offline Alice has option to form a new transaction and use service provided by another pool equipped with SlateStore protocol. I imagine this would be a competitive market, those nodes that have better uptime would get more profits. The output used by Alice gets locked only locally, nobody apart from Alice and Carol knows about this event. If Carol screws up someone else might earn this fee.
Post the link to the technical information here if you can find it.
There have been historically a lot of discussions on ānon-interactiveā transactions (transactions without the need to be online) with some reasonable solutions presented, but all come with some downsides in terms of complexity and scaling, which I why so far no decisions was made to implement them. I assume this is a similar solution. If it would be technically much different, it would make more sense to discuss it then if it is a solution which has already been discussed in the past.
Some past proposals for non-interactive transactions:
Unfortunately I could not find any details on how Beam made it work.
The protocol I advocate for is fully interactive, just interaction is coordinated via third party which makes it not necessarily for participants to be online at same time.
Personally I donāt see the problem with ć being interactive, especially if it brings scalability and/or privacy benefits.
I fully agree!
The problem is not interactivity, we just need to use interactivity properly and think of practical solutions such as a third party to fall back to in case the receiver is offline.
I wish we could cram more information in those slate-pack addresses, like a backup channel or third party address to send to. Ideally It would be like a small script of if this then than do that, if not possible do something else, like a smart contract.
Maybe I am going about it in the wrong way, it should not be in the slatepack address itself, it should be a QR code with in it a json that represent a small script that contains the slate-address and backup channels. In that way there is much lesss size restriction.
Maybe I am going about it in the wrong way, it should not be in the slatepack address itself, it should be a QR code with in it a json that represent a small script that contains the slate-address and backup channels. In that way there is much lesss size restriction.