> 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 -- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
