From rusty at rustcorp.com.au Mon Sep 5 02:25:22 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 05 Sep 2016 11:55:22 +0930 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <20160902120822.GA4575@nex> References: <87oa58ox54.fsf@rustcorp.com.au> <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> <20160902120822.GA4575@nex> Message-ID: <87y4376q25.fsf@rustcorp.com.au> Christian Decker 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.