mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

I agree with the need to enable non-repudiation in transactions. I originally had a simpler scheme in mind (basically the sender adds a nonce to the blinding factor, the receiver puts his blinded output, the sender subtracts the nonce*G from total and builds the sig) but there may be advantages in relying on the same scheme as mutlisig for this.

Could you just explain what the blinding factor ends up being on the receiver's output? I'm having trouble not making that depend on rI (which would defeat the purpose) when I factor in that (rO - rI) should be public key validating your signature. Thanks in advance!

- Igno

-------- Original Message --------
Subject: [Mimblewimble] defending against malicious transactors
Local Time: March 21, 2017 2:47 PM
UTC Time: March 21, 2017 9:47 PM
From: john.tromp@xxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx

The original whitepaper at
http://mimblewimble.cash/20160719-OriginalWhitePaper.txt
proposes the following transaction creation procedure:

1. Sender and recipient agree on amount to be sent. Call this b.

2. Sender creates transaction with all inputs and change output(s), and gives
recipient the total blinding factor (r-value of change minus r-values of
inputs) along with this transaction. So the commitments sum to r*G - b*H.

3. Recipient chooses random r-values for his outputs, and values that sum
to b minus fee, and adds these to transaction (including range proof).
Now the commitments sum to k*G - fee*H for some k that only recipient
knows.

4. Recipient attaches signature with k to the transaction, and the explicit
fee. It has done.

I see some problems with the sender revealing his total blinding
factor r though.

A malicious sender could spend this output himself while claiming that
the receiver took it, while a malicious receiver could spend the
outputs while claiming that they're already spent.

This malice could take place after the sender has prepared a
rangeproof for his change output, which the receiver could after all
intercept.

It therefore seems prudent to use a more involved procedure where the
sender need not reveal any blinding factors:

1. Sender and recipient agree on amount to be sent. Call this b.

2. Both sender and receiver pick a random blinding factor, rS and
rR respectively, and a random nonce, kS and kR respectively,
and share their commitments rS*G, rR*G, kS*G and kR*G

3. Both compute the Schnorr signature challenge e=H(kS*G+kR*G).

4. Sender computes sS=kS+e*(rS-rI), where rI is the blinding factor
on his input.
Receiver computes sR = kR+e*rR.
sS and sR are shared and verified against step 2 commitments by
multiplication with G.

5. The final signature is computed as (s,e) where s = sS + sR.

In this case the receiver learns nothing that lets her spend the
sender's output in any other way,
so no malicious claims can be made.
The above procedure is in essence how a 2-of-2 multisig output would
need to constructed.

Comments/feedback welcome.

-John

--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp