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

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.


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?


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.

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

Seriously however, what BitCryptex said:


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:


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


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

Now, the question is more clear to me.


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.

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.



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)

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?

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.

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:

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.

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.