Anthony Towns [ARCHIVE] / is on Nostr

📅 Original date posted:2015-09-28
📝 Original message:
Batch-replying.
On Sun, Sep 27, 2015 at 01:54:45PM +0930, Rusty Russell wrote:
> 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.
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 <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.
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 <aj at erisian.com.au> 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