From aj at erisian.com.au  Wed Dec 16 06:30:23 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Wed, 16 Dec 2015 16:30:23 +1000
Subject: [Lightning-dev] daemon/p2p protocol
In-Reply-To: <20151016205355.GA18796@navy>
References: <20151016205355.GA18796@navy>
Message-ID: <20151216063023.GA13482@sapphire.erisian.com.au>

On Sat, Oct 17, 2015 at 06:53:55AM +1000, Anthony Towns wrote:
> # lightning public keys...
> I think there are (at least) three uses for public key crypto in lightning:
>   1) routing keys -- used for constructing the onion.
>   2) anchor keys -- used for spending the anchor transaction for a
>      channel and thus signing commitment transactions; only needs to be
>      known by the counterparty you're constructing a channel with; can
>      be different for every channel.

I think you actually want separate keys for spending the anchor and
spending the commitments.

The anchor keys get used to sign every commitment, so it's probably pretty
important to make sure the secure random signing parameters chosen for
those signatures actually are secure. I guess using an HMAC scheme like
in RFC 6979 based on the anchor private key and a counter/nonce from the
commitment id probably works? secp256k1 seems to have a function for that.

The commitment keys might never actually be used if the channel is
closed cooperatively, which is kindof neat. Arguably it could be a
win for privacy to have a collection of these, so that if a channel is
unilaterally closed, you can't tell which transactions went which way
just by looking at the public keys. You wouldn't want to have too many,
though, because working out which commitment key you used for a particular
transaction might make enforcement of revoked commitments hard.

The commitment (public) keys need to be known to both parties to
construct/validate the p2sh addresses of course.

>   3) p2p keys -- used for establishing a shared secret when talking to a
>      node, to avoid your p2p communications being available to someone
>      else (either a passive observer or a MITM). could be different for
>      every connection, or could just have one the lightning instance.

Cheers,
aj (apologies if this was already obvious)