From aj at erisian.com.au  Sun Nov 22 02:13:27 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Sun, 22 Nov 2015 12:13:27 +1000
Subject: [Lightning-dev] Better privacy with SNARKs
In-Reply-To: <20151120074415.GA24674@navy>
References: <877fldmozx.fsf@rustcorp.com.au>
	<CAE8CtV=1uL-pcyhznYZMp4wyV1b6JcoeCJec9PBB9_Ow1VBjjQ@mail.gmail.com>
	<20151120074415.GA24674@navy>
Message-ID: <20151122021327.GA5726@navy>

On Fri, Nov 20, 2015 at 05:44:15PM +1000, Anthony Towns wrote:
> Hmm, I'm not sure if you can divide QN by (r2*..*rN) to get back to Q1,
> but I think you can [...] If you can,
> you even get the original receipt/proof of payment!

Yep, this works!

> _And_ I think you could just use SHA(ECDH_SEC || 3) as the r values at
> each stage rather than needing any additional entropy, or having to add
> any significant data to the onion packets.

This doesn't quite, though: if a txn routes from Alice through Bob to
Carol, with Alice/Bob's secret being p,P and Bob/Carol's being q,Q,
with p = q*r and P = Q*r; Alice has to pass on both p and q; p as part
of the HTLC contract, and q inside the onion payload because calculating
q=p/r is infeasible unless elliptic curve crypto is broken.

So add an extra 32B of payload to each onion hop if calculating r from
the ECDH secret is fine, or 64B of payload if it's not.

Cheers,
aj