[Lightning-dev] Ionization Protocol: Flood Routing
rusty at rustcorp.com.au
Sun Sep 27 04:24:45 UTC 2015
Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Sep 25, 2015 at 09:56:02AM +0930, Rusty Russell wrote:
>> [ Pieter Wuille Cc'd for pubkey recovery, search for "recovered" ]
>> Mats Jerratsch <matsjj at gmail.com> writes:
>> >> Indeed. Random selection helps, here, but analysis will be interesting.
>> > How have you ended up with a number of beacons you need? 12 seems so
>> > low, I can’t imagine so few nodes to support all transacting for even
>> > 10 minutes..
>> As we keep the last 100 sets of beacons, the load is spread a little.
> Does that actually work? Old beacons don't do any good if the payee
> doesn't use them when advertising a route; but old beacons also don't
> get their fee updates propogated, and aren't known by people who only
> just joined the network. I don't think you could usefully keep more than
> the last 2 or 3 sets of beacons?
I was thinking they all count as active. No point turning over all the
beacons every block.
>> To start, I was thinking you establish channels with 5 random nodes.
> I think Barabasi-Albert graphs are probably pretty reasonable here --
> you start by establishing channels to N nodes, selected randomly but
> favouring nodes in proportion to how connected they already are.
Interesting. If we assume growth only (as I suggested) we end up with a
geometric distribution (as backed by Section 5 of
It's not clear to me (without reading the paper) how much attachment
bias is required for a power law to apply, however. Larger nodes may be
incentivized (through profit) to have better uptime, leading to a slight
attachment bias. Definitely second order.
It's not clear that we want a power law: do we?
More information about the Lightning-dev