From rusty at rustcorp.com.au  Sat May 20 06:51:49 2017
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Sat, 20 May 2017 16:21:49 +0930
Subject: [Lightning-dev] Deterministic generation of H
In-Reply-To: <CAEspE8OquxC3mfuMyMOp41wWEo7EkN7aVFFDg50HKHMAKVuj+Q@mail.gmail.com>
References: <CAEspE8OquxC3mfuMyMOp41wWEo7EkN7aVFFDg50HKHMAKVuj+Q@mail.gmail.com>
Message-ID: <87k25cja0q.fsf@rustcorp.com.au>

Neil Fincham <easy2confuse at gmail.com> writes:
> Hi List,
>
> I have a question and if it has been discussed before please just point me
> to it and tell me to f off :) .  Also, if I am grossly misunderstanding
> things please feel free to correct me.
>
> Is there a way to deterministic generate H?

Yes, but not using the method we currently use.

> Further explanation:
>
> * With bitcoin addresses we have BIP32 that allows us to generate a Master
> Private Key, transform it to a Master Public Key and then use that Master
> Public Key to generate a series of addresses.
>
> We can generate addresses without the use of the private keys.
>
> * With LN we generate a random value S and hash it into H and distribute
> that and then finally distribute S in order to close the channel.

That's not quite right.  We use the terms "payment hash" for H and
"payment preimage" for S, BTW.  You use the preimage to fulfill the HTLC
(which is different from closing a channel).

> SO, my question:
>
> Is there a way to deterministic generate H like you can generate addresses
> with a Master Public Key without revealing S to the generator and still
> being safe to use S to close the channel?  (Hopefully I am not just
> confused and talking bullshit here)

You still need the payment preimage to close out the HTLC, but you could
certainly send out payment requests in such a scheme without access
to the preimages.

... but you can't do this with SHA256.  If we use a pubkey for the
"payment hash" and a privkey for the "payment preimage" we could exactly
use BIP32.

(There's an even more mindblowing scheme using Schnorr where the
signature *itself* serves as a kind of preimage, which we'll also need
to assess.  I think that would allow a similar partition scheme to
what you describe, but I'm not sure).

Hope that helps!
Rusty.