Mimblewimble Non-Interactive Transaction Scheme

Research
1

Request Your Comments :pray:t2:

Perhaps I’m resurrecting an old and long topic, for example here Is it technically possible that one can transfer grin even if the receiving party is offline? - #22 by Elwailly or a lot of others. But indeed I really strongly propose to evolve Mimblewimble to this direction, since the hard usability of current Mimblewimble wallet.

Recent releases in Grin already did a lot of good improvements in wallet, and took TOR+SlatePack as the middle-term (or long-term?) direction. It indeed works, just as we can see in the slatefest thread so far: Came Across 1st Grin ASIC of the World - #63 by kovri. It is quite convenient for command line users which has Tor installed and runnable, since a SlatePack wallet address enable user to listen and receive via Tor hidden service. But unfortunately, at least I would have these major concerns:

  1. In countries like China, Iran, etc, Tor does not work at all! So these users (not the ones of the most desired privacy users?) is being left behind, if not push out of the ecosystem.
  2. Mobile wallet problem. Tor service is hard (or even impossible for Apple devices?) to be integrated in mobile wallet. Then, a nice and easy to use mobile wallet for common people is more far than before.

That’s why I mention non-interactive transaction here again. This paper is following the basic idea which I mentioned in 2018 ("Pay-to-Address" / "Pay-to-Public-Key": Non-Interactive Transaction Solution for Mimblewimble : Mailing list archive : mimblewimble team in Launchpad), upgraded and merged with Stealth Address feature, ready for review here: https://eprint.iacr.org/2020/1064.pdf, sincerely request your comments on this scheme :pray: :sunny:

7 Likes
2

Mobile wallet problem. Tor service is hard (or even impossible for Apple devices?) dont know if that true but Tari already have ios mobil wallet with tor

3

Hi Gary,
Thanks for including me in the distribution of your paper. I went through it and understood it. It is very elegant. I especially appreciated your idea of including P’ in the output which limits access to the funds to strictly the receiver even though the transmitter knows r. I remember seeing that from you a while back.

Note that I don’t recommend changing anything but two ideas came to my mind.

  1. including R to allow the receiver to recreate k makes sense, but cannot we use an already available public key rather than reserve space in the output for R? I am thinking the P’ of inputs (the P’ the sender must use to gain access to the transaction inputs) can be seen by the receiver and therefore can do double duty to unlock inputs as well as generate k for the output transaction. That saves 32 bytes.
  2. I’ve always wondered why we need to lock out the sender from having access to the output funds after the transaction hits the chain. In other words, to fully receive the funds, the receiver creates a new transaction to transfer the funds to an r of his choosing as a final receiving step. In many ways this is more robust as the act of receiving is active rather than passive. If we allow this, the transaction does not need P’ to lock out the receiver. Recovering funds sent to the wrong receiver is also easy. Note that the receiving transaction can be very simple since it has only one input and one output. No need for range checking the output, which saves a lot.

It has been a disappointment to me how difficult it is to shift the Grin developers towards any of these ideas. They simply do not see how painful transactions currently are. I don’t really understand. It’s driven me away from following Grin lately.

As an aside, I loved your solution for coins anchored to fiat currencies in Gotts! lovely idea!

Best Regards,
Farid Elwailly

7 Likes
4

Hi Farid,

Thanks for your comments :+1:

To answer your questions:

  1. P’ can not do this double duty, because P’ need that R:

P’=H(a*R)*G+B

  1. About "I’ve always wondered why we need to lock out the sender from having access to the output funds after the transaction hits the chain. ", that’s mainly for payment proof. If both sides can spend this coin, it is very difficult to prove who eventually spend it. I thought about using another active receiving transaction, but I failed to find a way for payment proof. Do you have any new idea for that?

Best Regards
Gary

5

Just thought I’d mention that there is a way to run tor in china and other countries that restrict its access. You can use a different type of bridge. Although I have never tested its effectiveness.
https://tb-manual.torproject.org/bridges/

I don’t think tor was a perfect solution but was the best and most realistic option when implemented. At least until a better privacy protocol is developed like korvi.

1 Like
6

You say:

  1. P’ can not do this double duty, because P’ need that R:

P’=H(a*R)*G+B

I meant the P1 from the previous transaction. P1(n-1) is used to generate P1(n). (I assume the sender had to prove ownership of the inputs he is using. So he has a P1 for his inputs.)

You say:

  1. About "I’ve always wondered why we need to lock out the sender from having access to the output funds after the transaction hits the chain. ", that’s mainly for payment proof. If both sides can spend this coin, it is very difficult to prove who eventually spend it. I thought about using another active receiving transaction, but I failed to find a way for payment proof. Do you have any new idea for that?
    Consider that the receiver publishes A, a public key, PLUS a signature on A that proves A contains zero coins. (i.e. A is aQ, in other words A = aQ + 0H), The signature would not work otherwise. Now in the same transaction that the sender creates he can first select a sender q. He finishes all the proofs including the range proof, which he can do because he knows everything. Then, (and this is a hard fork step) he adds A to the output. (q ∗ Q + ar ∗ H) + (a *Q + 0 * H). The sender did NOT change the coins in the transaction (proof is signature on A). Sender does NOT need a NEW range check on the output. Now only the receiver that knows A can spend and the signature on A proves the identity of the receiver since A is a known public key for the receiver.

Finally, let me describe a completely different idea as well. It is incomplete so not workable yet but has good potential. I have been toying with a method to hide the transaction graph from Blockchain Analyzers. It is based on the realization that the creator of a block today needs enough information to verify the transaction balances, which makes the transaction public (not the actual amounts in Grin, but certainly the input and output “keys”). The insight I have is that the block creator could be limited to the task of ensuring NO DOUBLE SPENDS. The task of verifying balances really BELONGS TO THE RECEIVER. The receiver is the one motivated to get the balances right since he has to convince the next receiver that the balances are right OR NO ONE WILL ACCEPT HIS SPEND. The bulk of the transaction can be encrypted so only the receiver can decrypt and see it. This is a special encryption that can work backward so the receiver can open previous transactions in a chain until he arrives at the coin generation blocks.
Since a blockchain analyzer needs to receive a transaction before he can analyze its backward path, the graph is hidden from third parties. At some point, hopefully when the transaction is buried deep in the blockchain, a blockchain analyzer receives a transaction that he verifies backward until it spreads widely in the graph. But that can be far in the past. The more recent transactions have their sources and destination hidden. The issues I’m trying to solve are: 1) Making decryption of transactions backward in a chain possible for the receiver but not for third parties. 2) When spending, the transaction inputs have enough public information to leave a fingerprint that allows the block creator to block double spends, yet not reveal the sources of the inputs.
A possible alternative to 1) above is to have the sender include a chain of proofs of valid balances that he passes to the receiver. This can be verified quickly by the receiver and then can be augmented with the next step upon spending. I don’t like this idea as the chain can get quite large.

Best Regards,
Farid Elwailly

1 Like
7

I also thought about the bridges, but the GFW is quite strong and few current bridges works. Even I’m lucky enough to find a temporary bridge which works (for a moment), it is complex to need a further configuration to set up that bridge in the wallet, and another thing is the wallet does not support the bridge yet. So, basically, I think bridge is not the good solution for that.

8

:+1: :+1: I think that works :slight_smile: Thanks a lot for this bright idea!
So,

  • Rn = P’n-1
  • kn = H(kn-1*An-1) + bn-1
    where An-1 and bn-1 belongs to the sender self’s spending output.

Here I don’t understand well. Could you please explain more about your idea?
The problem here to be solved is the payment proof when both sides can spend the payment coin. In above non-interactive transaction scheme, that means no additional signature is needed except the transaction kernel signature (to prove he/she knows that q) when spending the payment coin. As the consequence, when Alice pay Bob 10 Grins but then she spend this 10 Grins by herself, how can Bob prove to the third party that he did not spend that 10 Grins?

And about your “completely different idea”, I need more times to read before I can get your idea :slight_smile: or if you have more specs about that, please let me know, thanks Farid!

Best Regards
Gary

9

Hi Gary,

You are right. If a transaction can be spent by either the sender or the receiver there is no proof that the receiver took possession of the funds. I’m sorry I didn’t make clear that I agreed with you on that. Let me clarify my comment;

I feel the situations requiring proof are not common and that generating a shared secret “q” for the output is fine if proof is not a consideration. The transaction sits on the blockchain for a bit until the receiver moves the funds to a secret of his own. This, for example, would be the situation among peers such as friends or a private transaction for a small purchase. However, the benefit of simpler (smaller) transactions may be outweighed by the inclusion of a second transaction to move the funds again and secure them.

What I was alluding to in my response is a transaction structure that is slightly different than your solution. It may or may not be useful, but I will describe it. Let’s assume we will want proof of receipt only in those situations where the receiver is not anonymous. This seems reasonable to me since if I am buying something where proof is an issue, the seller should be public. For example, I would use public transactions with sellers on eBay.

Such a transaction would look like a normal one but with a shared “q” as before. The sender at this point knows everything about the transaction and can complete all the required range proofs and commitments, etc., that are required to make the transaction a valid one and that others can verify. Let’s say the output is (𝑞∗𝐺 + 𝑎*r* ∗𝐻), where q is known to both sender and receiver. At this point we still have the proof of receipt problem.

Now, let us declare in this protocol that the output (𝑞∗𝐺 + 𝑎*r* ∗𝐻) is not spendable until it has been “covered” for the receiver. To cover the output, we add a public value to it. In our case let us add B to it. (Remember the receiver has a well-known (A, B) that he generated for himself). So, if B = b*G, the covered output will be (𝑞∗𝐺 + 𝑎*r* ∗𝐻) + B = ([𝑞+b]∗𝐺 + 𝑎*r* ∗𝐻). The covered output is obviously spendable only by the receiver.

Now the question is; how can we trust that B = b*Q and not B = bQ + xH, maliciously adding the value x to the output? The answer is to require the receiver to add a signature using B to his credentials that he publishes. I.e. the receiver publishes (A, B, sig[B]). This signature on B is only possible if x = 0. We cannot use B to sign anything unless B = b*G for some b, but not B = bG + xH. sig[B] is included with the covered output to allow anyone to prove the output coins have not been tampered with.

I’m sorry for the long description and I’m sure this is not better than the process you use. I was just trying to elaborate on my comment. I tend to be too brief normally and therefore not clear.

About my “completely different idea”, I’ve decided to write it up in more detail and will send you the writeup separately.

2 Likes