[Lightning-dev] [BOLT Draft] Onion Routing Spec

Christian Decker decker.christian at gmail.com
Thu Oct 20 13:40:47 UTC 2016


Just a quick update on my side: I have updated the spec as discussed during
the milan meetup and dropped the end-to-end payload, since we don't have
any good usecase for it currently.

I kept the shared secret backlog for now, since committing the routing
information to the payment hash is awkward: either we include the payment
hash in each per-hop payload, making it possible to stop a replay
immediately, or we add it to the last per-hop payload, at which point only
the last hop would be able to identify a replay attack, making it possible
to replay and observe traffic patterns. In both cases we'd be increasing
the per-hop payload size, which is pretty expensive to do.

Both the C-lightning implementation and the lnd implementations have been
adapted and can be used.

Cheers,
Christian

On Mon, Oct 3, 2016 at 11:34 PM Christian Decker <decker.christian at gmail.com>
wrote:

On Mon, Oct 03, 2016 at 05:21:35PM +0000, Olaoluwa Osuntokun wrote:
> > I think this only works if the on-chain keys are Schnorr, right?
>
> We'd use the same curve equation and domain parameters as Bitcoin uses
> currently, but would swap out EC-DSA for EC-Schnorr. So as a result,
> pub/priv keys stay the same, meaning the on-chain keys can be used for
> signing/verifying the multi-sign for channel authentication proofs.

So we'd still be using ECDSA for everything that could go to the
bitcoin blockchain, and use Schnorr for all other crypto
primitives. Sounds good to me, if we can be certain that reuse across
different schemes does not open us to new threats.

> > Separating onion privkey allows rotation; only a win if we get forward
> > secrecy (not a win for this node, as much as for the network as a
> > whole).
>
> Agreed, if we're not initially doing passive (or active) key rotation for
> the onion keys, then coupling the identity and onion keys simplifies the
> code at that level and nixes a few network layer control messages.

I'd argue that rotating the onion key is already valuable in order to
limit the shared secret backlog, allowing us to forget them after a
rotation, even if we don't have forward secrecy. If we can get forward
secrecy as well all the better though :-)

Cheers,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20161020/dfa568e8/attachment.html>


More information about the Lightning-dev mailing list