mimblewimble team mailing list archive

[John Tromp <john.tromp@xxxxxxxxx>]

> 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?

If the sender input is rI*G+a*H, then the receiver output will be
rR*G+b*H, and the change output will be rS*G+(a-b)*H.

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

sum of output minus input commitments is
rR*G+b*H + rS*G+(a-b)*H - (rI*G+a*H) = rR+rS-rI
which matches
s = sS + sR = kS+e*(rS-rI) + kR+e*rR = (kS+kR) + e * (rR+rS-rI)

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

-John