mimblewimble team mailing list archive
Mailing list archive
Re: defending against malicious transactors
> 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
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.