From matsjj at gmail.com  Fri Nov 27 14:44:19 2015
From: matsjj at gmail.com (Mats Jerratsch)
Date: Fri, 27 Nov 2015 15:44:19 +0100
Subject: [Lightning-dev] Better privacy with SNARKs
In-Reply-To: <20151127044219.GA4443@sapphire.erisian.com.au>
References: <877fldmozx.fsf@rustcorp.com.au>
	<CAE8CtV=1uL-pcyhznYZMp4wyV1b6JcoeCJec9PBB9_Ow1VBjjQ@mail.gmail.com>
	<20151120074415.GA24674@navy>
	<20151126111516.GA21851@sapphire.erisian.com.au>
	<87610ort9e.fsf@rustcorp.com.au>
	<20151127044219.GA4443@sapphire.erisian.com.au>
Message-ID: <CAE8CtVmUjHCnAY8YMChn63im2V5X-aT8iOAtvN7b8HRVK9wtzA@mail.gmail.com>

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.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html

Cheers,
Mats

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