SlateStore Protocol

Development and Technical Discussion
#1

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.

8 Likes
#2

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

#3

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

#4

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
#5

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
#6

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?

#7

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
#8

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.
#9

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
#10

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.

2 Likes
#11

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:

#12

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
#14

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
#15

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
#16

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
#17

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