This is another take on non-interactive transactions.
I had posted a failed attempt in the past here
Recently, Gary Yu proposed a scheme that modified current Mimblewimble transactions. "Pay-to-Address" / "Pay-to-Public-Key": Non-Interactive Transaction Solution for Mimblewimble
in an Email To: firstname.lastname@example.org
In this writeup I propose allowing non-interactive transactions based on the insight that the Rangeproof and the commitment to zero H multiplier can be separated to allow sending to a pay-to public key.
I’ll develop the method following these steps: Alice is sending to Bob
- Bob publishes a “send-to” key with a signature proving no H-Multipliers in his public key
- Alice generates a transaction on her own to her own blinding factors and with range proofs on her own outputs as well as zero H multiplier signatures
- Each one output in her transaction, now proven to be in range, is forwarded to one recipient cover by re-blinding it for the ultimate recipient. Since we have (single input goes to single output) we can say this step requires no range proof. However, we still require a zero H-multiplier proof. This is done as follows
- To preserve Bob’s anonymity, Alice generates a private shared secret with Bob , q, for the purposes of this transaction
- Alice generates a blinding factor for Bob based on his “send-to” key and the shared secret and applies it to one of the transaction outputs
- Alice generates a “ Sender Generated Signature ” on the transaction output that proves that the output minus the input has no H-multiplier.
The main difference in transactions is that each output has an extra blinding step after the range proofs are done .
Receiver Publishes a Receive Public Key with “Zero H-Multiplier” Signature
Bob publishes a “Send-To” key, “B”, with secret “b”. Where B = bG.
Bob also publishes a signature to prove the H multiplier is zero in his public key:
r = Hash(b)
R = rG
s = Hash(G)b + r
The signature, (R,s) with public key B, proves the H multiplier in B is zero.
Sender-Generated Zero H-Multiplier Signature
The insight here is that Alice can generate another signature for Bob from his published one with the same desirable property. Alice has a private key, a, with public key A = aG. Alice, generates a shared secret with Bob as follows:
q = Hash(m,aB) where B is Bobs public key and m is unique to this transaction
Note q is now a shared secret between Alice and Bob since Bob can generate it with q = Hash(m,bA)
Now notice that multiplying both sides of Bob’s Schnorr signature by the shared secret produces another relationship that still holds the properties we desire.
q (s = Hash(G)b + r) which expands to qs = Hash(G)qb + qr
So, given [(R,s) B], Alice can generate [(qR, qs) qB], renamed [(R’,s’) B’], which is a signature that proves that the H multiplier in B’ is zero. (B’ = qB, if B’ has a non-zero H multiplier then B must have one as well, which is a contradiction.)
Sender Generated Blinding Factor
Alice now uses B’ as the difference of the blinding factor for Bob and her blinding factor (Bob’s public blinding factor can be calculated from the difference) and publishes (R’,s’) as the proof that B’ has a zero H multiplier; verifiable as s’G = Hash(G)B’ + R’ (from qs = Hash(G)qb + qr )
Both Alice and Bob know the shared secret q, but only Bob knows b’, the secret part of B’, since b’ = qb and only bob knows b.
By careful choice of A and m, Alice and Bob will never interact.
- A is selected as the curve point corresponding to the blinding factor the sender, Alice, is using on the input coins.
- m is selected as the Hash of unique parts of the input.
- Bob, the recipient, has a wallet that checks all new outputs by retrieving A and m, calculating a q = Hash(m,bA), and checking that B’ has the property that B’ = Hash(m,bA)B
- The wallet then calculates Bob’s blinding factor from B’, determines the sent balance, and adds the balance to the total Bob has in the wallet.
No interaction between Bob and Alice outside the transaction required!