From rusty at rustcorp.com.au Mon Sep 21 02:16:13 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 21 Sep 2015 11:46:13 +0930 Subject: [Lightning-dev] Ionization Protocol: Flood Routing In-Reply-To: References: Message-ID: <874mioecuq.fsf@rustcorp.com.au> Hi Amos, I'm delighted that someone else is thinking about routing! I like the information hiding features, but I don't think this will scale if everyone floods the network before sending a transaction. I do, however, have an alternate scheme which is something of a middleman, which I'd appreciate your feedback on. We regularly choose a dozen "beacon" nodes at random (using proximity to the SHA of latest block hash or something). Everyone propagates the cheapest route to & from those nodes (which is pretty efficient, similar to your scheme). To receive a payment, B picks a few beacon nodes at random and sends those routes (beacons -> B) to A. Presumably A knows its route to all the beacon nodes and thus can choose the best. There are some twisty details here: 1) How many beacon nodes? 12, and increase on a log scale with network size. That size can be derived from previous beacons. 2) How long between selection and a beacon becoming active? 10 blocks. That gives time for others to connect to beacon node. 3) How long before a beacon node is invalid? No idea. Let's keep a day's worth for the moment? 4) How to avoid fake beacons? Require a signature attached to an unspent bitcoin TX from before beacon selection? That TXID is actually what competes to be close to the beacon selector. 5) How to update beacon routing? Particularly for fee changes, this is important. Best effort, with ratelimiting. I hope eventually we'll have reasonable traffic models so a node can say "I'm going to ramp up/down my fees for this long at this rate" and have a reasonable chance that it's true. Cheers, Rusty. PS. For the immediate term, we'll use a global comms mechanism like IRC, but that's just a prototype hack. Amos Bairn writes: > Here is a scheme I thought of for flood based route finding. If it can be > pulled off it would allow efficient route finding while keeping the shape > of the network hidden, as well as giving onion like anonymity. > > After writing it up a realized that it has a trivial denial of service > attack, that could render it a non-starter. > > I'm throwing it out there anyway, because this could have significant > potential if the DoS problem can be solved. > > https://github.com/Eylrid/ionization/blob/master/ionization.mediawiki > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev