From aj at erisian.com.au Fri Sep 25 05:08:36 2015 From: aj at erisian.com.au (Anthony Towns) Date: Fri, 25 Sep 2015 15:08:36 +1000 Subject: [Lightning-dev] Ionization Protocol: Flood Routing In-Reply-To: <87a8sbs5t1.fsf@rustcorp.com.au> References: <8761314tpn.fsf@rustcorp.com.au> <38D4A6A1-474D-49A4-8380-76B65AFBEB70@gmail.com> <87a8sbs5t1.fsf@rustcorp.com.au> Message-ID: <20150925050836.GA11549@navy> 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 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? > 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. https://en.wikipedia.org/wiki/Barab%C3%A1si%E2%80%93Albert_model Cheers, aj