[Lightning-dev] Better privacy with SNARKs

Mats Jerratsch matsjj at gmail.com
Fri Nov 27 14:44:19 UTC 2015

I love how people come up with sneaky solutions to force the other
party to reveal the private key somehow. But given that we might have
dozens of HTLCs in a commit transactions or also payments that pay to
two (or more) payment keys (is this the new term for it now?) we
should maybe strive for a more clean solution.

I have summarized most of the information of this discussion and
'handed in' a BIP request to the bitcoin-dev mailing list. If the use
case is good enough (and I think it is) and there are little draw
backs (can't think of any security-relevant one), there should not be
too much resistance.



2015-11-27 5:42 GMT+01:00 Anthony Towns <aj at erisian.com.au>:
> On Fri, Nov 27, 2015 at 02:25:09PM +1030, Rusty Russell wrote:
>> Anthony Towns <aj at erisian.com.au> writes:
>> > The alternative approach, which andytoshi and I came up with
>> > independently is a lot more complicated:
>> >   revealP( Q, R, sigA, sigB, sigC ) {
>> >     check_multisig_verify(2, P, R, 2, sigA, sigB); code_separtor();
>> >     check_multisig_verify(2, Q, R, 2, sigA, sigC); code_separtor();
>> >     check_multisig_verify(2, P, Q, 2, sigC, sigB);
>> >   }
>> > If sigA, sigB and sigC all share the same r and SIGHASH settings,
>> I don't think this works?  We can't provide the signatures in the
>> scriptPubkey, since that requires them signing themselves.
> The scriptPubkey has the pubkey P, and a whole mess of stack operations
> to implement the function above; the scriptSig just has Q, R and the
> three signatures.
>> We can't
>> have them provide it in the scriptSig, since theres no "do these have
>> the same r value" operator in script.
> There's six sig ops, but only three different signatures. Getting the
> various combinations to have the same signature forces the same r value
> between each of the signatures, without needing a separate op to check
> it explicitly.
> It's mathematically possible to come up with Q, R, sigA, sigB, sigC where
> sigA.r, sigB.r and sigC.r are all different; but it requires being able
> to come up with a transaction with a particular hash, or calculating the
> discrete log of a weird value to do so, so should be safely intractable.
> Cheers,
> aj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

More information about the Lightning-dev mailing list