Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-16 📝 Original message: Other post was quite long ...

📅 Original date posted:2015-10-16
📝 Original message:
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