From matsjj at gmail.com Fri Oct 16 13:23:34 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Fri, 16 Oct 2015 14:23:34 +0100 Subject: [Lightning-dev] Specifications of Broadcasting Layers Message-ID: Other post was quite long already and they are actually dealing with two different issues. So currently I can think of 3 different broadcast messages, that are differently dynamic and needs different handling, so I attach them each with a new signature (which bloats a lot unfortunately). (1) Pubkey-Channel-Relationships (see other post on ML) Very static, relayed every 10 days 264 Bytes (2) Node addresses/IP Depends on the nodes (dynamic/static IP), approx every 12h 133 Bytes (some estimate, as I want to support addresses too, not just IPs) (3) Channel-Status (capacity, fee, ...) Highly depending on actual traffic and node usage - once an hour? 176 Bytes (estimated, depends on actual content) I would love to combine (1) and (3) to save the 80B of an additional signature, but at the same time (1) is not worth an hourly broadcast. Furthermore, I would spare some additional bytes in (1) for some reputation system (yes, I really am into these.) These three add up to 2.5GB daily data, or 30kb/s constant load. For hard drive space it is around 330MB. I think we can either realise it as some kind of gossip protocol (easy to implement, overhead of an efficient gossip protocol can be very low) or use some DHT approach (difficult to bootstrap, has to be designed to be highly resistant to failure/highly redundant). A new node would want to retrieve the full dataset similar to the blockchain before actually opening a channel with a new node. So we need to design a way of retrieving the full dataset for fresh nodes, probably in some load-distributed way, although 330MB isn't too much to retrieve from 1-5 nodes. (and 100k nodes is a pretty optimistic view of the network too currently, although rusty usually starts even higher...) Mats Jerratsch