[Lightning-dev] Ionization Protocol: Flood Routing

[Rusty Russell]

Anthony Towns <aj at erisian.com.au> writes:
> On Fri, Sep 25, 2015 at 06:26:55AM +0930, Rusty Russell wrote:
>> >> >> 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.
>> >> > I think it's also something you could set per-node, like the
>> >> > minrelaytxfee.
>> >> That doesn't make sense, since we need to agree on who is a beacon.
>> > If you have the top 10 beacons and I have the top 14 beacons, we have
>> > the top 10 beacons in common. During the gossip phase, if either of us
>> > see someone in the top 10, we pass it along; I pass along a few more as
>> > well.
>> If I want to pay you, and you give me those 4 beacons I don't accept, we
>> break down.
>
> I have 14 beacons, and I know the order in which you're most likely
> to have them. If I know you can choose how many beacons you track,
> why would I give you the four you're least likely to have (because you
> have a lower limit, or because you've heard of four better beacons that
> haven't made it to me yet)?

Ergo, there are only 10 beacons, since that's all you'll ever use?  So,
you *don't* get to choose your number of beacons.

Anyway, I won't propagate fee broadcasts which don't alter my proximity
to a beacon.  So if I'm between you and something only you consider a
"beacon", you'll never know about it.

And in practice it's trivial to agree on the number of new beacons for
this block, given the beacons for previous blocks (assuming we want
number of beacons to grow with the network).

In summary, having your own beacons basically defeats the purpose of
selecting beacons.

> Since I have to update my beacon-to-me routes regularly because of fee
> changes, I could regularly select different groups of beacons so you
> could just ask again.

Yech... you really want this to be single pass "pay me $5, and here are
three routes from beacons near me".

>> > Sure. I was thinking you have to volunteer to be a beacon, ie something
>> > like:
>> >
>> >   1) commit to node id (anchor transaction in blockchain)
>> >   2) commit to ordering (abs difference of node id versus 
>> >      sha of latest blockchain block with (depth % 2016 == 0))
>> >   3) volunteer to be a beacon (sign "imma beacon! depth $n anchor
>> >      $txid")
>> >   4) gossip (including your signed volunteer statement) and hope you're
>> >      in the top 12
>> > Any preparation (opening new channels etc happens between (2) and (3)),
>> > transactions happen immediately after (4).
>> We don't want to have to maintain a table of volunteers, hence 3 & 4 are
>> merged (simple optimization: delay advertising yourself as a beacon
>> longer if it's less likely).
>
> If you want to do any setup, I think you need to advertise yourself as
> a beacon to the people you want to setup with. I'm thinking that if you
> win the beacon lottery, you'll want to say "hi, I'm about to be a beacon"
> so people will setup channels with you without you having to put much
> initial investment in that channel. The people setting up channels with
> you see a bunch of people doing that, and will only want to deal with the
> top 12 or so. I'm not sure that's much different to actually advertising?

Well, my original idea was a beacon can just start broadcasting routes
and see what happens.

But you're right makes more sense to have two-phases: an immediate one
after the block is broadcast where you compete (via SPV proof of some
tx) to be a beacon, then another closer to activation where you
broadcast routes.  Between those two you can expect an influx of channel
offers.

Interestingly, the former idea means you get some leakage of routes,
from nearby almost-beacons (until defeated by better beacons).
Remembering those might help shortcircuit some routes (if there's some
geographical correlation between nodes).

>> Then by convention you delay 10 blocks before using a beacon.  By that
>> time, routes should be sufficient.
>
> I wouldn't have thought 10 blocks was long enough to setup a new channel
> especially to a beacon, fwiw. (If you can create a channel to a beacon
> with the beacon's side initially 0, spend all that money back to yourself,
> then reorg with a doublespend of the anchor inputs so the channel never
> existed, you can steal the beacon's pre-existing savings. The routing's
> trivial -- it's you to the beacon, and then each of your neighbours will
> tell you the cheapest path from a beacon to them as soon as they know it)

I guess I was thinking of microtransactions, and expecting the average
anchor depth requirement to be ~1.  6 is considered pretty conservative;
I only added 4 to allow for propogation and setup time.

>> > I'm not sure if it's a realistic attack model, but if you can observe:
>> >
>> >   Bob -> Alice: pay me $20 to R (routes to current beacons: ...)
>> >
>> > and have control of the beacon Alice ends up using, then you can both
>> > observe that Alice is trying to make the payment (you see an HTLC with
>> > $20 and R), and prevent Alice from making the payment (you can just not
>> > forward any transactions involving R).
>> Sure.  But if you can observe the private conversation between Bob and
>> Alice, *and* you control enough nodes that you're likely to be the
>> beacon they choose, you don't need to be a beacon to block them :)
>
> You don't have to control the nodes initially, you just have to attack
> the beacons once they're announced. If they're accepting new channels,
> then they've announced an IP. If you get an exploit on a node that
> would have been #15 in the ranking, you just have to DoS three higher
> ranked beacons to get it to have traffic.

They're still beacons though, they're just useless.  You do need to get
a beacon then DoS enough others to force traffic though you.  That may
be cheaper than offering the best rates, I guess.

>> Yes!  I've been wondering about this kind of "donation address"
>> scenario.  Turns out you can encode the R value in the onion routed
>> message you send, too.  Only the final recipient can read it anyway.
>
> Yep.
>
>> That doesn't help with routing to the donation address; maybe we will
>> need a best-effort DHT for that?
>
> If you've got a route, but no fee information; you could probe the
> route with nanopayments. ie, to move $10 along me->A->B->C->D, first
> try sending 0.01c to B with a 0.1% then a 0.2% fee, etc. Once you know
> A's fee, repeat with B, then C. If the fees end up as 1%, 2% and 0.2%
> your successful transactions are:
>
>   0.01c to B plus 0.0001c to A
>   0.01c to C plus 0.0001c to A plus 0.0002c to B
>   0.01c to D plus 0.0001c to A plus 0.0002c to B plus 0.00002c to C
>   $10 to D plus 10c to A plus 20c to B plus 2c to C
>
> and the txs that had smaller fees just bounce back to you.

I was assuming the "insufficient fees" message would include the latest
route info, so it's even easier.

I was more concerned about the "there's no channel from B->C any more".

> (If probing was the main use for nanotransactions, nodes might set higher
> fees on them though, if they assume you've already chosen a route, and
> they therefore don't need to compete on price with other possible routes)

Maybe nodes will offer some kind of routing service in future.  Seems
like it'd be a layer up though.

>> > ie, nodes do payment forwarding; wallets just spend/recieve. You'd use
>> > your phone as just a wallet, but you might run a node at home or in
>> > the cloud. Wallets still do the lightning protocol themselves, they just
>> > don't earn fees by forwarding payments.
>> I think you do want to 
>
> "run a node on your phone" ?
>
> In order to gain node-like return on your investment, I think you'd have
> to be constantly active -- so updating your routes, tracking beacons,
> etc. You'd miss out on ever being a beacon presumably, which would
> pretty severely cut into your income to nodes that are beacons -- though
> maybe you could sell your beacon-worthy private keys and recoup some of
> that? I don't see how anyone would feel confident to buy your private
> keys though.
>
> Your phone would need to be doing fairly constant network access while
> it was in your pocket as it forwarded HTLCs; 24k transactions per second
> over a million nodes at 5 non-beacon hops is still around 7 tx/minute
> for a random node. Each of those comes with multiple crypto ops as
> well. So you'd be burning battery afaics. If you're only doing it while
> you're plugged into AC, then I'd expect your ROI to drop proportionately
> (so instead of $10 from $100 over a year, maybe $3.50 if you leave your
> phone on charge every night).

Constant connectivity is getting easier.  You'd stop accepting new HTLCs
once you wanted to go idle.

> It'd also up the latency for people routed through you a fair bit;
> phones aren't that fast, and aren't that well connected. So any payment
> routed over one would be that much slower than one that went via servers
> on fibre. If you're slow to process a transaction and more likely to
> lose connectivity, that ups the chances of an HTLC stalling -- you've
> accepted it, but you lost connectivity while trying to forward it, so
> everyone else is out of pocket until you get signal back.

Yeah, you lose a channel for that.  Could end up costing you more than
you'd make in profits.

> Forwarding also introduces the risk that all your funds are tied up in
> active HTLCs when you want to buy a coffee.
>
> I just don't think everyone running a full node trying to make a profit
> off routing is realistic.

You're probably right; and poor nodes might help the theoretical
decentralization of the network while degrading overall practicality.

But phones will get better.  

>> > Aside: "mesh network" seems to be a much better description than
>> > hub-and-spoke... cf
>> > https://www.reddit.com/r/Bitcoin/comments/3lo8mb/serious_question_for_blockstreamcom_will_you_let/
>> Thanks for that: I'd somehow missed that troll.
>
> Seemed like a legit question to me *shrug*.

If it didn't contain a kernel of validity, it wouldn't be a troll,
right?

> There's a corresponding thread
> (same title) on BitcoinXT, if you really want to feel trolled.
>
> There's also:
>
>   /r/lightningnetwork: The Bitcoin Lightning Network
>
>   This sub-reddit is dedicated to corporate interests trying to take over
>   the decentralized world-wide ledger.
>
> No posts unfortunately...

Damn, let me fix that...

> (Caveat one: Maybe phones are so insecure there's no way to have a private
> key that's reasonably convenient, but also "safe" while "offline". You
> could mitigate that by introducing a second factor; having $10 on your
> phone most of the time -- coffee and bus fare money, that you don't care
> much if someone steals -- but having a secondary lightning wallet that
> you can only use by tapping a crypto-NFC smartcard for when you want to
> pay for dinner or recharge your primary wallet, eg. Having your phone
> be secure directly would be better though)
>
> (Caveat two: There's no reason not to forward transactions while you're
> online and your private keys are in memory -- err, assuming they don't
> lock up too many funds anyway; I just think there's good reason to be
> online as little as possible)

OK, if we have a real offline mode for standard wallets, the distinction
becomes real.

> As far as privacy goes I think you could tell which of your neighbours
> is using lightning primarily as a wallet versus trying to be a
> profit-generating node fairly easily: wallets will have smaller channels,
> there'll be fewer transactions over them, and they'll disconnect more
> often. That doesn't guarantee they're not forwarding things; but if they
> are they're almost certainly arranging it out of band anyway (even if
> only to know when they'll be online and thus able to forward).
>
> (I actually think arguing the other way might make a bit of sense; if
> you're running a node, you should pay profits and expenses to/from an
> entirely separate lightning wallet)

I think deniability is important.  Thus I would want my wallet to
forward payments when offered.

>> > (Or going the other way; if you're making money running a node, I think
>> > it's pretty reasonable you'll try to serve on the order of 100k users
>> > -- much less than that and you'll be under utilising your hardware. But
>> > with only 8B potential customers, there's a limit on the number of nodes
>> > that can actually do that, as calculated above. I'm assuming economics
>> > somehow ends up enforcing that limit effectively)
>> >
>> >> which uses hosted wallets or something?  I don't think that's very
>> >> interesting.
>> >
>> > Not hosted wallets; more along the lines of SPV clients, where you're
>> > relying on the network to do most of the work (in this case working out
>> > a cheap route, rather than verifying txns)?
>> But the "give me a cheap route" question is exactly the same whatever
>> your role.  It's "give me all your routes to beacons".
>
> I was talking about the beacon-less alternative here, where nodes have
> the full weighted-directed-graph of channels and fees to work out a route.
>
>> That's a few hundred routes.
>
> Also, with beacons, you don't need to know all their routes to beacons,
> just their cheapest route to each beacon, so that should be just 12
> routes (unless we're working with a few hundred beacons now?). No
> matter which route from them, it'll always just be the same You<->Them
> channel beforehand, so cheapest via them will just be that plus their
> cheapest. You need to keep all your neighbours' cheapest routes to
> fall back on if someone else raises fees though, if you're not willing
> to repoll.

Yes, exactly.  Routes propagate proportional to number of beacons.  Even
with hundreds, it's still cheap.

Cheers,
Rusty.