SlateStore Protocol

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.

11 Likes

What would happen if Alice comes online and finds Bob online?

Then no need for any protocol. They can just interact between each other.

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?

1 Like

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.

1 Like

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.

1 Like

Currently, as explained by @david in this post

the modified flow would consist of three actors: sender (Alice), receiver (Bob) and intermediary (Carol)

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. Alice sends Ae, Ar to Carol
  2. Carol sends Ce, Cr to Bob
  3. Bob adds all the excess and nonce, adds their output and sends back to Carol with his partial sig
  4. Carol adds her output with fees and adds her partial sig and sends to Alice
  5. Alice finalizes the tx
1 Like

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.

3 Likes

Thank you for helping to clarify 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.

  1. Can Alice provide her final partial signature without knowing Bob’s offset?
  2. 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?

I’m a bit lost here I admit :sweat_smile:

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.

1 Like

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.

2 Likes

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.

2 Likes

What happens in the event that

  • Alice sends transaction to Bob (Via Carol)
  • Carol receivevs transaction for Bob and then goes offline, permanently

Can Alice simply cancel the transaction? e.g. not finalise?

1 Like

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.

2 Likes

Beam has a public offline address. I will try to draft a RFC for this idea.

6 Likes

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.

2 Likes

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.

:thinking: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.