Olaoluwa Osuntokun <laol...@gmail.com> writes:
> Hi Rusty,
>
> I think this change may be a bit misguided, and we should be careful about
> making sweeping changes to default values like this such as fees. I'm
> worried that this post (and the subsequent LGTMs by some developers)
> promotes the notion that somehow in Lightning, developers decide on fees
> (fees are too low, let's raise them!).
Phew, I'm glad someone else is uncomfortable! Yes, I held off this
kind of proposal for a long time for exactly this reason. However,
the truth seems to be that defaults have that power, whether we want
it or not :(
If we make defaults more awkward, it will encourage people to change
them. In the end, I settled on a simple number because I want to to
be easy to filter out these defaults from further analysis.
> IMO, there're a number of flaws in the reasoning behind this proposal:
>
>> defaults actually indicate lower reliability, and routing gets tarpitted
>> trying them all
>
> Defaults don't necessarily indicate higher/lower reliability. Issuing a
> single CLI command to raise/lower the fees on one's node doesn't magically
> make the owner of said node a _better_ routing node operator.
No, but those who put effort into their node presumably have more
reliable nodes, and this is a signal of that.
Anyone have data on channel reliability that they can correlate with
channel fees?
> If a node has
> many channels, with all of them poorly managed, then path finding algorithms
> can move extrapolate the overall reliability of a node based on failures of
> a sample of channels connected to that node. We've start to experiment with
> such an approach here, so far the results are promising[1].
That's great if you're making many payments, but then you have many
heuristics at your disposal. Most people won't be making many
payments, so such techniques are not useful.
>> There's no meaningful market signal in fees, since you can't drop much
>> below 1ppm.
>
> The market signal one should be extracting from the current state is: a true
> market hasn't yet emerged as routing node operators are mostly hands off (as
> they're used to being with their exiting bitcoin node) and have yet to begin
> to factor in the various costs of operating a node into their fees schedule.
> Only a handful of routing node operators have started to experiment with
> distinct fee settings in an attempt to feel out the level of elasticity in
> the forwarding market today (if I double by fees, by how much do my daily
> forwards and fee revenue drop off?).
>
> Ken Sedgwick had a pretty good talk on this topic as the most recent SF
> Lightning Devs meet up[2]. The talk itself unfortunately wasn't recorded,
> but there're a ton of cool graphs really digging into the various parameters
> in the current market. He draws a similar conclusion stating that: "Many
> current lightning channels are not charging enough fees to cover on-chain
> replacement".
This is all true, too.
> Developers raising the default fees (on their various implementations) won't
> address this as it shows that the majority of participants today (routing
> node operators) aren't yet thinking about their break even costs. IMO
> generally this is due to a lack of education, which we're working to address
> with our blog post series (eventually to be a fully fledged standalone
> guide) on routing node operation[3]. Tooling also needs to improve to give
> routing node operators better insight into their current level of
> performance and efficacy of their capital allocation decisions.
Assuming a network in which many people are running nodes for their
own use and only forwarding as a side-effect, the biggest factor will
*always* be the default settings.
BTW, a quick look at the percentiles (ignoring "default setting" channels):
Percentile Min Capacity Max Capacity Median Base Median PPM
(sats) (sats) (msat)
0-10 1100 100000 0 10
10-20 100000 200000 1 10
20-30 200000 358517 1 8
30-40 358517 546639 1 10
40-50 546639 1000000 1 42
50-60 1000000 2000000 106 10
60-70 2000000 3143170 2 35
70-80 3145265 5550000 1 800
80-90 5561878 16000000 0 800
90-100 1600000 200000000 0 1
Overall: 1 10
>> Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
>> and seems to have significant usage, so there clearly is market tolerance
>> for higher fees.
>
> IIRC, the fees on that node are only that high due to user error by the
> operator when setting their fees.
No; fiatjaf measured incorrectly and thought he was charging 5% and
there was much confusion. It was always 0.5%, as it was supposed to be.
> Independent of that, I don't think you can draw the conclusion that they
> have "significant" usage, based on solely the number of channels they have.
> That node has many channels due to the operator campaigning for users to
> open channels with them on Twitter, as they provided an easy way to package
> lnd for desktop users. A node having numerous channels doesn't necessarily
> mean that they have significant usage, as it's easy to "paint the tape" with
> on-chain transactions. What really matters is how effectively the node is
> managed.
Can Pierre weigh in with some usage information?
> In terms of market signals, IMO the gradual rise of fees _above_ the current
> widely used default is a strong signal as it will indicate a level of
> maturation in the market.
Those conditions are met, it seems?
> Preemptively raising defaults only adds noise as
> then the advertised fees are less indicative of the actual market
> conditions.
Preemptively? How do you decide when to that is? I agree low defaults
were great for testing, but they're probably distorting the market now.
> Instead, we should (to promote a healthier network) educate
> prospective routing node operators on best practices, provide analysis
> tools t
> hey can use to make channel management and liquidity allocation decisions,
> and leave it up to the market participants to converge on steady state
> economically rational fees!
If there's no anchoring effect of the defaults, then there's no harm in
changing them; at least increasing them would serve as a reliability signal
(assuming that's true).
If they are distorting the market, we should change them so the market
can be more efficient.
Cheers,
Rusty.
"We just need to educate everyone" is not really going to get us there,
is it? We want almost all users running nodes, and the benefit of them
to tweak things is so small they're just going to stick with the
defaults.
In the long run, "defaults" will get smarter (eg. based on a comparison
of other similar channels), but I suspect we'll see anchoring around
*todays* defaults.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
