[Lightning decentralisation] Routing around hubs

[Carlton Banks]

• could Lightning decentralisation be improved by giving node operators a "do not route thru X" config option?
• could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?
• how might this affect fees?
• how might this affect liquidity?
• how (if at all) might this inter-operate with delegated (i.e. "trampoline") routing?

trolls/trolling not tolerated

please post questions and/or answers

[DaveF]

• could Lightning decentralisation be improved by giving node operators a "do not route" config option?
• could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

trolls/trolling not tolerated

please post questions and/or answers

I would think that doing either of these could cause problems. It's supposed to be an "open" system.
If you start to allow this, then some big players can come in and start to determine where they want their BTC to go.
If Alice does not want to route to Bob, Chris or Dave but Carlton is ONLY routing to Bob, Chris and Dave. You never get BTC from Alice.

Working on no sleep, so I might be missing something but at 1st glance allowing what you said could cause that.
Yes it's a edge case, but if your node now has to route around this because you both DO talk to Steve, the programming logic just gets that much more complicated.

-Dave

[Carlton Banks]

Dave, you're confusing "routing" and "payee"


All payees would be reachable, but hubs could be routed around in order to lessen their influence on the network (using your example, the only way one couldn't recieve money from an invoice issued to A would be if A only has open channels with hubs that B, C and D are routing around)

additionally, DONOT-route(hubA, hubB) could easily be PREFERENTIALLY-route-around(hubA, hubB)


this would be user controlled, opt-in. that is in no way contradicting the open nature of the network, it is intended to help reinforce openness


so you've misinterpreted the whole idea completely, unfortunately

[Rath_]

could Lightning decentralisation be improved by giving node operators a "do not route" config option?

Node operators are already able to create private channels which are not announced to the rest of the network. This is why mobile wallets do not route payments. I don't think that it affects decentralisation in a positive way, but forcing someone to route payments is pointless and could be frustrating.

could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

What if some nodes somehow faked (lowered) the number of their channels? A channel is considered not capable of routing when it is offline. What if it could be exploited in some way?

how might this affect fees?

Wallets would have to have some sort of protection against overcharging (Eclair Mobile allows you to stop the payment if the fee is higher than 3% of payment's value). Some invidual nodes might have their fee policy set to ridiculously high values. Most big HUBs will offer low fees and short routes at least at the beginning.

[Carlton Banks]

could Lightning decentralisation be improved by giving node operators a "do not route" config option?

Node operators are already able to create private channels which are not announced to the rest of the network.

I don't mean that at all

I mean:

public nodes, with publicly announced channels, NOT routing through specified nodes (e.g. nodes with high amount of channels) to prevent routing from becoming dominated

What if some nodes somehow faked (lowered) the number of their channels? A channel is considered not capable of routing when it is offline. What if it could be exploited in some way?

right, sybil style de-identifying. LNbig already split themselves into multiple nodes, but (obviously) they continue to identify themselves as LNbig run nodes


that's why I also mention positive preferential routing, i.e. a "please use these nodes to route, if possible" routing algorithm

that way, a node operator can choose a bunch of nodes for whom they know (or are at least confident) are run by small independents, and make sure those small independents always get favorable treatment when routing

possibly, large trampoline (routing delegation) nodes could be similarly shown routing preference if they have a "good" preference list, but I don't think it can be proven that trampoline nodes were using routes that avoid hubs, at least with how the Lightning routing protocol works now... not sure about this

[DaveF]

Dave, you're confusing "routing" and "payee"


All payees would be reachable, but hubs could be routed around in order to lessen their influence on the network (using your example, the only way one couldn't recieve money from an invoice issued to A would be if A only has open channels with hubs that B, C and D are routing around)

additionally, DONOT-route(hubA, hubB) could easily be PREFERENTIALLY-route-around(hubA, hubB)


this would be user controlled, opt-in. that is in no way contradicting the open nature of the network, it is intended to help reinforce openness


so you've misinterpreted the whole idea completely, unfortunately

And that is why I try not to post before coffee :-)

Seriously however, what BitCryptex said:

I don't think that it affects decentralisation in a positive way, but forcing someone to route payments is pointless and could be frustrating.

And what I said about more complicated programming logic are true.

Yes, you can argue that "don't use this node" is no more of a programming issue to route around then "this node is offline don't use it"
But as the network expands the more options you add the more things can not work as intended.

Using exactly what you said:

All payees would be reachable, but hubs could be routed around in order to lessen their influence on the network (using your example, the only way one couldn't recieve money from an invoice issued to A would be if A only has open channels with hubs that B, C and D are routing around)

Yeah, that's going to be a VERY VERY VERY rare case. Why give people the option to have it happen?

could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

I understand what you are saying that this in theory might help I just see it being gamed by people.
"Oh, people want to use nodes with fewer channels, cool, instead of having 1 big one with lots of channels I'll spin up a ton of smaller ones and charge a higher fee"
 
-Dave

[Carlton Banks]

Seriously however, what BitCryptex said:

I don't think that it affects decentralisation in a positive way, but forcing someone to route payments is pointless and could be frustrating.

you both need to read the OP again

could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

I understand what you are saying that this in theory might help I just see it being gamed by people.
"Oh, people want to use nodes with fewer channels, cool, instead of having 1 big one with lots of channels I'll spin up a ton of smaller ones and charge a higher fee"

if "don't use this route" gets gamed, "do use this route" cannot be


if you fail to understand this a second time, you won't be posting in this thread again, as unfortunately there's little difference between someone who cannot grasp something and someone who pretends not to be able to grasp something in order to be obstructive

[Rath_]

Now, the question is more clear to me.

could Lightning decentralisation be improved by giving node operators a "do not route thru X" config option?

Unless the vast majority of LN users exclude or lower the priority of large HUBs, it won't make that much of a difference. It's kind of 'vote with your wallet'. I don't think that's an issue since more layers are going to be built on top of the Lightning Network, so an avarage Joe will use different layers while more experienced users will know about priorities.

It looks like LND allows to ignore certain nodes while querying possible routes (ignored_nodes parameter). The outputs can be used in SendToRoute, so it's already possible to do what you suggested manually using LND. SendPayment does not have such feature but it is possible to select the first node which will route the payment.

[ajas]

could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

Yes, the routing is done by the sender, so he can decide to exclude
certain nodes, or nodes with more than nmax open channels. But this
requires some programming and struggling with the command line
interfaces of the lightning clients, I have not done that so far.

I do something similar when opening channels. I do not use the
'autopilot' feature of lnd but wrote my own algorithm to select
destination nodes: choose the nodes so that the number of hubs
required to enable me to send a certain amount of btc to every node in
the network is minimized, excluding routing through hubs with more
than 30 open channels.

By doing this one would set up a network that is more
decentralized. But I cannot claim that my node is excessivly used. (I
think the acceptance of lightning is still very poor).

If you want to have a look at my node and have any comments, its called
'node1'.

[Carlton Banks]

Unless the vast majority of LN users exclude or lower the priority of large HUBs, it won't make that much of a difference. It's kind of 'vote with your wallet'.

I agree, but smaller operators of nodes might only ever number in the 10's of thousands. I hope there will be more, but who knows. Simply by discussing this, it could eventually reach the eyeballs those 10's of thousands while they (inevitably) look for ways to improve their node's competitiveness.

It looks like LND allows to ignore certain nodes while querying possible routes (ignored_nodes parameter). The outputs can be used in SendToRoute, so it's already possible to do what you suggested manually using LND. SendPayment does not have such feature but it is possible to select the first node which will route the payment.

this is useful information.


I still think that the 'sybil'¹ problem exists. And so what of a "route through this node, if we can" type of routing logic? Has anyone implemented that? What problems could it cause?


A problem with the "avoid this route" routing logic is that, depending on how many nodes are circumvented, the routing calculation will likely increase in time and complexity, and possibly also fee amount. This problem depends a great deal on the precise network topography and it's liquidity distribution, but certainly the worst case will be affected.


¹(it's not really the proper definiton of sybil, as it's not an attack on the connectivity or topography of the network)

[Wind_FURY]

• could Lightning decentralisation be improved by giving node operators a "do not route thru X" config option?
• could the obverse be achieved by allowing clients to preferentially route through nodes with some definition of "fewer" channels?

It might improve decentralization but it would be less-efficient. The reality is, hubs/specialization will always form for efficiency, and a smoother UX. But it's OK, because anyone can be a hub themselves, plus users can always circumvent the hubs, anytime.

[Carlton Banks]

The reality is, hubs/specialization will always form for efficiency, and a smoother UX. But it's OK, because anyone can be a hub themselves, plus users can always circumvent the hubs, anytime.

I guess we need to define what we mean when we say "hub"


"hub" to me would mean the nodes with the most disproportionately high liquidity on the network. by that definition, not everyone can be a hub (let's for argument's sake say the top 20 highest liquidity nodes are hubs).

does that mean a literal hub & spoke network topology will form around these nodes? the answer to that so far is "no" (despite rather hilarious attempts by trolls to post screenshots of lightning network topography depicting uncountable numbers of connections going between huge quantities of small nodes). it's a fact that the network graph is massively complex even at this early stage; if you took an isolated view of big liquidity providers, a hub and spoke topography is evident. but there are far more regions within the network graph where smaller nodes are connected to one another than those dominated by hubs.

the purpose of this thread is to kick around some ideas to encourage the continuation of that. as has been said, in an open access system, there's nothing to stop someone providing more liquidity than others as they see fit, and also nothing to stop someone spreading their liquidity across several nodes to obscure shared ownership.


so maybe here's another way of looking at the same thing:

if you were a big liquidity provider on LN, and wanted to dominate the network, how would you do it? using multiple smaller nodes is one obvious way, but this pushes your costs up in a marketplace that's easy to join. and the network topography is constantly changing, a position in the network graph might become less relevant frustratingly quickly.

• might competitiveness be found by over provisioning node/channel count, keep the majority nearly empty, connecting them all together, then re-balancing liquidity to where it's needed, or where it is somehow predicted to arise?
• could wannabe hubs over-provide liquidity massively and simultaneously undercut fees of smaller nodes, hoping that doing so for long enough will push them out of the market?
• perhaps some exclusivity deals with large businesses using Lightning?
• or exclusivity through deals with financial regulators?
• using a strategy for causing valid routing to fail, where they make some trade-off that failing at one node within a route has an increased likelihood that a recalculated route will use more of their nodes?

how else could someone try to be dominate LN? any objections/solutions to the above?

[darosior]

• could Lightning decentralisation be improved by giving node operators a "do not route thru X" config option?

For what it worths, it's already implemented in C-lightning (the 'exclude' parameter in getroute).

So the question is do users actually use it ? It's been here for a long time and I've only seen plugin which use it (like "pay" to try multiple routes). In addition to users, who the implication in route gathering should (/will) be limited in the future (the aim is autopiloting everything), will the autopilot algorithms have a decentralisation concern ? If yes would they be less efficients than ones without concern ?

I think the only treshold is user incentive : if a "hub" tries to increase fees then an autopilot would try other routes, but if the "hub" is part of the most efficient route (which represents a real operational cost, and a real exposure), then I don't think (to answer the quoted question) that it would improve decentralisation at all.

[PrimeNumber7]

I don't believe what you describe is reasonably possible. It is not possible to authoritatively rule out any given node being part of a specific "hub" because one entity could possibly be running multiple nodes. If enough people start intentionally routing payments around large "hubs", some entities will start forming multiple, smaller hubs, and limiting the number of open channels they will allow each of their nodes to connect to, that are intended to appear independent.

This would both increase fees, and decrease liquidity. When you decline to transact with particular entities, you have fewer remaining options, and when there are less service providers providing services to the same number of customers, prices will generally increase (supply goes down, and demand remains constant). If there is total LN liquidity of 100 BTC, but 30 BTC is tied up in large nodes that you want to avoid, the total network liquidity has dropped to 70 BTC, however you will also generally need to use longer routes than if you were allowing payments to be routed via a "hub", and there is a greater chance one or more leg of the route will lack liquidity.

how else could someone try to be dominate LN?

One could drive up the cost of being a liquidity provider. They could do this by opening channels to competing "hubs", and stop coorporating with the operator, causing them to close the channel, and pay for doing so in the form of tx fees.

This is probably another likely way:

using a strategy for causing valid routing to fail, where they make some trade-off that failing at one node within a route has an increased likelihood that a recalculated route will use more of their nodes?

Fees are already nearly zero, and I don't think many hub operators are making much money currently, so I don't think undercutting on fees is a realistic proposition.

[Wind_FURY]

The reality is, hubs/specialization will always form for efficiency, and a smoother UX. But it's OK, because anyone can be a hub themselves, plus users can always circumvent the hubs, anytime.

I guess we need to define what we mean when we say "hub"


"hub" to me would mean the nodes with the most disproportionately high liquidity on the network. by that definition, not everyone can be a hub (let's for argument's sake say the top 20 highest liquidity nodes are hubs).

In reality/economically, yes not everyone can be a hub. But technically, and by design, you can be. But it's early days, let's see how it matures.

Plus, to start the network, I'm for the hub and spoke model. Trolls laugh, but it's more efficient.

[spartacusrex]

What about an option where you always route through the smallest-hub routes ?

If 2 routes are available choose the one with the least amount of money on it.  ( These smaller routes would have to re-balance more often to stay relevant. )

You would only use the big hub routes as a last resort - if no other viable cheap enough route was available.

This may require more hops, and may require more fees.

Would you always choose the cheapest route or would you choose the most helpful route to keep the network decentralised ? .. not sure.

I pay the 'higher' fee currently on my BTC transactions, even if time isn't such an issue, so I can see myself choosing the _slightly_ more expensive route, if the money still got there, and it was beneficial to the health of the network.