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

Rusty Russell rusty at rustcorp.com.au
Mon Sep 5 02:25:22 UTC 2016


Christian Decker <decker.christian at gmail.com> writes:
> I'd like to pick up the conversation about the onion routing protocol
> again, since we are close to merging our implementation into the
> lightningd node.
>
> As far as I can see we mostly agree on the spec, with some issues that
> should be deferred until later/to other specs:
>
>  - Key-rotation policies

OK, I've been thinking about the costs of key-rotation.

Assumptions:
1) We simply use a single pubkey for everything about a node, aka its ID.
2) Medium-scale public network, 250,000 nodes and 1M channels.
3) Every node knows the entire public network.

Each node ID is 33 bytes (pubkey) each channel is 6 bytes (blocknum +
txnum).  You need to associate channels -> ids, say another 8 bytes per
channel.

That's 22.25MB each node has to keep.

The proofs are larger: to prove which IDs owns a channel, each one needs
a merkle proof (12 x 32 bytes) plus the funding tx (227 bytes, we can
skip some though), the two pubkeys (66 bytes), and a signature of the ID
using those pubkeys (128 bytes, schnorr would be 64?).

That's an additional 800M each node has to download to completely
validate, and of course some nodes will have to keep this so we can
download it from somewhere.  That's even bigger than Pokemon Go :(

Change Assumptions:
1) We use a "comms" key for each node instead of its ID.
2) Nodes send out a new comms key, signed by ID.

That's another 33 bytes each to keep, or 8.25MB.  To rotate a comms key,
we need the new key (33 bytes), and a signature from the id (64 bytes),
and probably a timestamp, (4 bytes), that's 25.25MB.

That's not too bad if we rotate daily.  Probably not if we rotate
hourly..

Cheers,
Rusty.


More information about the Lightning-dev mailing list