From aj at erisian.com.au Mon Sep 28 10:37:19 2015 From: aj at erisian.com.au (Anthony Towns) Date: Mon, 28 Sep 2015 20:37:19 +1000 Subject: [Lightning-dev] Ionization Protocol: Flood Routing In-Reply-To: <878u7sqvp6.fsf@rustcorp.com.au> <87612wquxr.fsf@rustcorp.com.au> <87bncoqyk2.fsf@rustcorp.com.au> Message-ID: <20150928103719.GA6341@navy> Batch-replying. On Sun, Sep 27, 2015 at 01:54:45PM +0930, Rusty Russell wrote: > Anthony Towns 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 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. Okay, in that case I was misled by your original description. You're actually talking about n*k beacons at any point in time, of which the oldest k are replaced every d days. If k=12 and n=8, that gives 96 beacons at any point in time. Any given beacon is operation for n*d days, for n=8, then d=1 gives 8 days, while d=7 gives 2 months. The "d" parameter would be "consensus-critical"; I don't think it's possible to agree on any beacons without agreeing on d. You could vary k or n as the network scales though, but in that case I think it'd generally be easier to vary n than k? If you identify a given beacon by its cohort (from 1..n), its rank (1..k), its visibility (how long ago you first heard about it in seconds) and its currency (how recently the last route update to that beacon was), then I think the odds of a random other node also knowing about that beacon works out as: - worse for the most recent cohort (older cohorts should have more fully propogated) - potentially worse for the very oldest cohorts + if being a beacon wears you out (channels may have been used up; they may have been hacked; they may have cashed out their profits and bought an island) + if nodes have varying settings for n, so older cohorts don't have as effective route propagation - worse for recent visibility (newly advertising beacon, that hadn't fully propagated, same deal as for a new cohort) - worse for non-recent currency (beacon might be offline, or routes to that beacon might have failed) - worse for low rank in recent cohorts (new beacons shouldn't show up for old cohorts; if new beacons show up in recent cohorts, its the low rank beacons that will be offloaded) - worse for low rank in any cohort if other nodes have lower values for k When picking beacons to advertise for accepting a payment, I think you'd want to take most of the above into account, to avoid only suggesting coincidently unreachable beacons, and having the payment fail. I don't think you could really take route price into account, since the real price is "consumer to beacon" plus "beacon to merchant"; and those could trivially be inversely related. Having 10%-30% of your suggestions be selected by cheapness would still be useful though. Choosing, say, two of the cheapest beacons, and three beacons from cohorts 3-n with recent currency and long term visibility would probably work okay though. If nodes are identified by a 160b address, and it takes around 4 hops to get to/from a random beacon, then a route is 4*160b=80B and five routes as above is 400B. That's ~550 bytes with base58 encoding by my count, or about 7 lines of 76 column text. Kinda lame: "please pay to 1ajaj31PWNVZEzd68S8PqAPof4EFbeZaf via lightning route: 5PSGzi9R6k6G2mdFPx2ZsfyVdiz9gSaA7EegpTvzbxLb13yMEuNuK7m1DhJuJvwkMe4BrfdU2V5q cKf825oYmikQMzpfAvVkavA3AyXZEgGWx9j3j5gUxMUE8LhawnfTWWSQMc2gChzKEz1puFcyveMa QHVdhbcJY73M4Aev7KDWqnrAYNid2keGRzDtUDfZarSsABR4RWjshCtBctekjvxYQpsBqD4NrzvV DCGQNNWbKibSawkt18xdPGxR3rwMwkEqU5rE8EfXmFrFaj7t2nB8DWQa1oe4QhvPe9BYsyAumJtG SZFmRknJ2E5feDCzYfqAu8tVcaW6yhKUgxdrxqBVfzdTBFVtt2p5PPrz4C9d3MQsrerfSHSbbX7Q VcUqhotinoMHX2UyfbRYX4BJgNjLqaXE33EthhF7BBmBRkP6V7EyZYrc53XtEi1ocuKNiejWcEQe neajEMR9rFpHHSnzSX8AXXn13TYsGirHiFG7KYu7tzg6EFEifLeAz2wxaaaMs2K6J488kxWpDy1s GtG3zX3v5msToo" (I 100% approve of urandom generating bytes that encoded to "aj" twice in the length I estimated for a route... Sure, it probably means my RNG is compromised and identifying me, but how sweetly personalised!) > >> 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 > Interesting. If we assume growth only (as I suggested) we end up with a > geometric distribution (as backed by Section 5 of > http://www.e-publications.org/ims/submission/index.php/BEJ/user/submissionFile/10315?confirm=c40442a0 > ). > It's not clear that we want a power law: do we? I was more thinking that it's what we'll get without any particular effort. The more connected a node is: - the more likely you'll hear about it (via p2p), so the more likely you'll connect to it, versus a node you don't know exists - the more it will earn from fees, so the more funds it will have to connect to you out of the blue - the cheaper its routes to other nodes (beacons, consumers, merchants) will be at least by path length, so the more attractive it will be for connecting to (at least, I think?) so the more likely you'll connect to it by happenstance, and the more happy you'll be that you did. On Sun, Sep 27, 2015 at 02:56:29PM +0930, Rusty Russell wrote: > Anthony Towns 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. Or I choose 3 from the top 10 and 1 from the bottom 4, and have the top 10 used 90% of the time and the bottom 4 10% of the time? > 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. If 25% of the network uses 14, and 75% uses 10, but the 25% is a strongly connected subgraph, I'll know about the routes to the next four. Maybe they won't be the optimal routes to those beacons, and thus won't often be the cheapest routes, and thus won't often get used, but it still all works fine. As other people switch and it gets to a higher percentage, you get a smooth transition from k=10 to k=14. I think bumping n=8 to n=9 or n=10 would work similarly. If you're going to have parameters that need to be changed as things scale, seems useful to have them accept changes gracefully, rather than relying on flag days. I'm still pretty sure that k (and/or n) here work that way, as described. > > 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". Well, so far a "route" consists of a path with fees; symbolically: pay [MY ADDRESS] $5 via: [BEACON 1] 1c [N1A] 1c [N1B] 2c [N1C] 2c [N1D] 4c [ME] [BEACON 2] 2c [N2A] 1c [N1C] 2c [N1D] 4c [ME] [BEACON 3] 1c [N3A] 3c [N3B] 1c [N3C] 1c [N3D] 1c [ME] So even if you keep the same set of beacons, you have to regularly update the route info as fees/routes change, eg: pay [MY ADDRESS] $5 via: [BEACON 1] 1c [N1A] 1c [N1B] 2c [N1C] 2c [N1D] 4c [ME] [BEACON 2] 2c [N2A] 2c [N2B] 1c [ME] [BEACON 3] 1c [N3A] 3c [N3B] 1c [N3C] 1c [N3D] 1c [ME] (N2A to N2B dropped it's previously uncompetitive fee from 10c to 2c in this example, nothing else changed. N1C->N2A costs 8c) Even just sitting on the "checkout" page for a minute might be long enough to require a new route suggestion, eg. If you're doing that anyway, might as well select a different set of beacons each time as well. (The only way to not have to do that (afaics) is to just say "pay [MY ADDRESS $5" and query the network for the route; which either means keeping the entire graph available for path finding, or having DHTs to lookup routes from beacons and fees) > 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. If you've got n cohorts of beacons anyway, it seems like you'd just always have the newest cohort be "in setup phase". ie, they'd announce and compete fairly quickly (minutes or hours), and then spend some time getting fully setup (new channels, rebalancing), and obviously still forwarding any transactions that find their way to them, but everyone would still tend to use the more established cohorts. Then once the /next/ cohort gets selected, it's game on. That'd just require merchants to not select the latest cohort of beacons when advertising routes from beacons. As far as everyone else is concerned, brand new beacons are fine to use as normal if they turn out to be the best route. > 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). I don't think this works: old route info also means old fee info; and you can only shortcircuit if the fees are actually less, which you no longer know. > >> 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 don't think microtransactions help reduce risk here: from one angle, if you're spending $10,000/year on hardware and admin time to keep your node operating, you want to make that much in revenue to pay for it, and if revenue is 20% ROI per year, that's $50,000 investment or more on your side of your channels. ie, I'm expecting to see serious money locked up in channels. (If forwarding a txn earns you 0.2%, then $10k/year in fees means forwarding $5M/year, so $13k/day, $600/hour, $10/minute, or 15c per second on average. If your average transaction is $10, that's one a minute; if it's 10c, it's three every two seconds, etc.) Now, if you're always receiving paired transactions (10c from Alice to Carol, then 10c from Carol to Alice, then 10c from Alice to Carol again, etc), you don't need more than 10c in your channels to forward the payments, and your profit isn't dependent on your investment, and life is pretty sweet. But if there's time discrepencies so that Alice pays multiple rounds of 10c to Carol, who then batches it up into a single $10 payment, you need $10 in your channel (100x more). Or if Alice and Anna and Amy and Abby all pay multiple rounds of 10c, then eventually Carol accumulates that into a burst of 50x $10 payments, you need at least $500 in your channel with Carol, and a similar amount distributed across the channels connecting you to the A-squad. And if the reason you're connected to the "A-squad' is that you've got a cheap connection to a beacon, that's centralised in that one channel. If there's multiple Carol's each batching $500 in received funds together at the end of the day, your channel balances have to scale accordingly. If you don't, you'll miss out on transactions, and hence fee income. (So, if you need $50k across your channels (making up your $50k investment mentioned above), that's $25k on each side, and you're making $10k a year in fees, off of $5M/year in transactions (again, as above), then that means your channels are able to cover about two days' worth of discrepency -- ie if you start balanced with $25k on your side of the Alice-you channel, and the same on you-Carol, after 46 hours worth of microtransactions at $13k/day, you can't accept payments from Alice or to Carol anymore. So I think this directly relates the ROI to... fee percentage and standard deviation of payment frequency on a channel? Something like that) *However* this is all probably a moot point: if beacons aren't used while they're in the newest cohort, then they don't particularly need to use the new channels immediately, and new anchors get safely buried anyway. Something like: * 1 hour (6 blocks): pretty good global consensus on who the beacons are * 20 hours (120 blocks): plenty of time to setup new channels * 3 hours (18 blocks): plenty of time for the new channels to be buried And voila, 24 hours later, the new cohort has new channels and is ready to go active, and a new newest-cohort can be chosen. > >> > 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. If a beacon stops responding to pings, it won't be able to announce fee updates, and would presumably expire. I'm assuming you'd just keep using the k best beacons you've seen recently, so that would allow new guys in as well. It feels a lot like doing economic stimulus by randomly selecting some people, giving them a million dollars, and announcing their home addresses. Sure, it's the first story on the news, but the second is how they were found mugged and broke two hours later... Okay it's not a million dollars, it's mmore transactions. So how's beacon profitability compare to regular nodes? Assume 100 beacons, 100k regular nodes doing forwarding, $20M/day (250k tx/s at 10c/tx), and aggregate fees of 1%/tx. Shortest path between random nodes is ~4 hops, so actual tx path is about seven intermediaries: CONSUMER-a-b-c-BEACON-e-f-g-MERCHANT. So every transaction pays 6 nodes and 1 beacon. Assuming they break the fees down evenly, beacons get 1/7th of all transactions fees; remaining nodes get 6/7th of all transaction fees. So an average beacon gets: 1/100 * 1/7 * 1% * 20M = $285.71/day 1/(100k-100) * 6/7 * 1% * 20M = $1.72/day If you're talking about millions of nodes, that's another factor of 10 or more worse. If you're talking 100k nodes but 1000s of beacons instead of 100, maybe it gets better ($15-$30/day vs $2/day?), but then maybe we need to revisit the beacon related traffic calculations, because 1000 is a lot more than 12... In reality, to me those numbers just say "it's not worth running a node if you're not a beacon", so the best strategy is to commit a few cents in pretend channels on the blockchain to buy tickets in the beacon lottery, but only start actually routing when you win. So there maybe ends up being a few thousand nodes that have direct relationships with customers to earn profits based on subscription fees, and a bunch of beacon-specialists who play the beacon lottery and run 90% of the beacons at any given time, earning profit from investment and routing. Also, if the only routes you know are to and from beacons, it seems a bit difficult to do much in the way of "scenic" routing to make the onion routing more obscure. I'm not sure this actually matters if you have a total path length of more than six or seven though. (TBH: at this point beacons are seeming (to me) like a clever idea, that's totally implementable, but won't actually work out at all. YMMV obviously) > >> 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 figuring it would just be a "couldn't route" message with no additional info (could be no channel, not enough fees, bad R, mistake in crypto...) -- otherwise you're kind-of unwrapping the onion (ie, C tells B, "C's fee is 1%"; B tells A "C's fee is 1%"; A says "oh, trying to send money to C, huh? how interesting!". C could encrypt the info to the symmetric key A sent C, but... seems like a lot of hassle at that point) > I was more concerned about the "there's no channel from B->C any more". Sure. In that case you can't make the payment until they tell you new routes, or you use some other protocol for route finding. The beacons are going to change soon enough anyway, so no suggested route will work for all that long, even ignoring fee changes. > > (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. I kind-of think routing is actually already a layer up, and effectively sort-of pluggable. ie, you've got: 0: direct connection to someone, can establish a channe, update HTLCs 1: onion-routed packets, can be forwarded on level 0 2: route-finding If you've got a bunch of beacon routes, that's one way of implementing level 2. If you know a whole bunch of channels, then you can do it that way. If you have an oracle you can query, that's another way. If you've got multiple different systems (some nodes don't participate in the main routing network because of persecution fears eg), with some nodes in common, you can join them up. > > 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... Still no posts; caught in moderation I guess? > > ... > OK, if we have a real offline mode for standard wallets, the distinction > becomes real. Without it, I guess I'm thinking of balances like: - $10-$20 on my phone (coffee, busfare, wifi access) - $100-$200 on my desktop/laptop (which I can turn off, and have more control over) (Ideally, I'd rather have $200 on my phone though, replacing cash/credit for everyday purchases) Things that can't go offline don't change of course: - $1-$10 for IoT devices doing micropayments - $10-$100 for routers/cloud computers paying for their own internet - $1000-$5000 for merchants doing reasonable volume - $1000-$100,000 for nodes operating as revenue generating investments > > 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 think deniability is important. Thus I would want my wallet to > forward payments when offered. Sure, but I think in practice that only works if you actually forward payments; otherwise "you claim that payment was forwarded; but in the five months we've monitored you, you have not forwarded a single payment, why should the jury believe this one was special?" If you had $1000 on your phone, and were *actually* acting like a node, and willing to be a beacon, then *that* would be totally deniable, and pretty awesome. But I think in practice technology will mean you've got some nodes acting as an investment trying to earn a ROI/profit, and other nodes acting as wallets, spending money or receiving money based on goods/services outside of lightning itself. > > (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) So pulling in the other mail here: On Sun, Sep 27, 2015 at 03:12:56PM +0930, Rusty Russell wrote: > Anthony Towns writes: > > On Fri, Sep 25, 2015 at 11:23:42AM +0930, Rusty Russell wrote: > >> Beacons are going to get slammed, but it's not clear how bad it is. > >> Getting slammed from all directions doesn't use up channels; it's only > >> computational and bandwidth limits. > > It does actually use up channels -- if you've got 5 channels with 100 BTC > > in them collectively in total, and you own 20 BTC of that, and collect > > a 0.1% fee on each transaction, you'll gain 80 BTC after 80,000 BTC are > > forwarded through you, and nobody will be able to send you funds any more. > That's a great insight! Fees *do* erode channels. I had totally missed > that. What I'm thinking is you'd do something like: - node has $10,000 in channels, earns 20% a year, so around $150 a month - once a month, roughly, node owner has the node pay $150 from the node to a personal lightning wallet - payments for node's running costs can be made from wallet (avoiding hitting the blockchain) - the personal wallet can get pushed to the blockchain providing anchor transactions for new channels for the node (to reinvest the profits) Benefits: - you can lock the profits in an offline wallet if you want (you only need to be active long enough to receive the HTLCs, and you can decide when to send them) - if you have the node, you can't trace the money to the hosting environment - node's channels are refreshed and can stay open indefinitely - if you hit a lucky channel that's makes $1000/month with only $100 channel balance, you can keep that channel active forever (you'd have to empty profits out once a day or so though) - you can kind-of lock the node down, so that it will only sign incoming/forwarded transactions, and outgoing transactions to a particular wallet (probably have to limit to set of known R values though). you could come close to having this be just a trusted crypto module, and have any exploit in the rest of the system be unable to steal your money. Hmm, I think that actually explains the lightning/bitcoin fee nexus a bit: lightning nodes earn x% of lightning transactions; then to reinvest this profit in lightning, they spend on the blockchain generating $f in fees for miners. It's not /spending/ the profits from lightning fees that generates fees for miners (because that could be done withing the lightning network in theory), it's /reinvesting/ them in the lightning network. (And also buying into lightning in the first place, or cashing out eventually, or rebalancing your investment) > > (In the event that someone suggests a route beacon_X -> X -> Y -> Z to > > get to them, and you have a path A -> C -> X -> beacon_X, you can cut out > > the middleman and not route through a beacon at all. I don't think this > > gives much of an improvement though. A beacon could potentially avoid > > this from being possible by partitioning its neighbours into two sets > > and setting incoming fees for one set prohibitively high, and outgoing > > fees to the other set as prohibitively high; managing that dynamically > > would be difficult but I think possible) > But you'd risk not being used as a beacon if your fees are too high. That's not a problem here. Say every other beacon costs 1% to route through, give or take. You have neighbours A, B, C and D. You set the following prices: A -> Me: 0.45% B -> Me: 0.45% Me -> A: 5.1% Me -> B: 5.1% C -> Me: 5.1% D -> Me: 5.1% Me -> C: 0.45% Me -> D: 0.45% A route that goes X -> A -> Me -> C -> Y will still only pay you 0.9% so is completely competitive for transactions; but hardly anyone will ever see a route like Z -> D -> C -> Me, because Z -> W -> V -> U -> A -> Me will be cheaper despite the extra hops. That in turn means means no one will figure out that Z -> D -> C -> Y is a valid path, missing out going through me. To make it work dynamically, you'd need to swap the channels you apply the ~5% penalty so the transaction flows balance out, but I think the general principle works. > It > seems to me that a beacon wants many connections, to avoid the > "short-circuit" case. At 100 connections, it's only 1%, though > that's the best case which assumes they're all equally likely. Maybe... Establishing an extra 100 connections per beacon per cohort is a fair chunk of blockchain transactions; and presumably they'll expire once the beacon stops being a beacon, rather than lasting for months/years. 500kB per cohort, maybe? At 1MB/block and a cohort per day, that's 0.3% of the blockchain already. (Is 100 realistic, or would every node want a direct channel to a beacon, so that it would be more like 1000/beacon (100k nodes, 100 beacons) or more?) > Good points. If we reject all routes less than (say) 3 hops by default > it might mean that local payments are *less* efficient. Oops. I was thinking, at least at this stage, that there wasn't any point differentiating local vs global payments; I'm hoping global payments are quick enough for buying a coffee anyway, and online microtransactions will probably be global anyway. And as above, I think route finding is separate enough that you can always improve it while leaving the lower layers (HTLCs and onion-forwarding) the same. Cheers, aj