Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-11 📝 Original message: Hi Rusty, I think this ...
📅 Original date posted:2019-10-11
📝 Original message:
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!).
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. 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].
> 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".
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.
> 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. `lnd` exposes fees on the command line
using the fixed point numerator which some find confusing. We'll likely add
another argument that allows users to specify their fees using their basis
points (bps) or a plain old percentage.
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.
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. Preemptively raising defaults only adds noise as
then the advertised fees are less indicative of the actual market
conditions. 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!
[1]: https://github.com/lightningnetwork/lnd/pull/3462
[2]:
https://github.com/ksedgwic/lndtool/blob/graphstats/lightning-fee-market.pdf
[3]:
https://blog.lightning.engineering/posts/2019/08/15/routing-quide-1.html
On Thu, Oct 10, 2019 at 7:50 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> I've been looking at the current lightning network fees, and it
> shows that 2/3 are sitting on the default (1000 msat + 1 ppm).
>
> This has two problems:
> 1. Low fees are now a negative signal: defaults actually indicate
> lower reliability, and routing gets tarpitted trying them all.
> 2. There's no meaningful market signal in fees, since you can't
> drop much below 1ppm.
>
> Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
> and seems to have significant usage, so there clearly is market
> tolerance for higher fees.
>
> I am proposing that as of next release of c-lighting, we change defaults
> on new channels to 5000 msat + 500ppm, and I'd like the other
> implementations to join me.
>
> Over time, that should move the noise floor up. I picked 500ppm because
> that's still 1% at 20 hops, so minimally centralizing. I picked 5000
> msat base for less quantifiable reasons.
>
> Here's default fee a rate table in USD (@10k per BTC):
>
> Amount Before After
> 0.1c 0.0100001c 0.05005c
> 1c 0.010001c 0.0505c
> 10c 0.01001c 0.055c
> $1 0.0101c 0.1c
> $10 0.011c 0.55c
> $100 0.02c 5.05c
> $1000 0.11c 50.05c
>
> Thoughts?
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/a52bb47f/attachment.html>;
📝 Original message:
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!).
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. 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].
> 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".
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.
> 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. `lnd` exposes fees on the command line
using the fixed point numerator which some find confusing. We'll likely add
another argument that allows users to specify their fees using their basis
points (bps) or a plain old percentage.
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.
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. Preemptively raising defaults only adds noise as
then the advertised fees are less indicative of the actual market
conditions. 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!
[1]: https://github.com/lightningnetwork/lnd/pull/3462
[2]:
https://github.com/ksedgwic/lndtool/blob/graphstats/lightning-fee-market.pdf
[3]:
https://blog.lightning.engineering/posts/2019/08/15/routing-quide-1.html
On Thu, Oct 10, 2019 at 7:50 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> I've been looking at the current lightning network fees, and it
> shows that 2/3 are sitting on the default (1000 msat + 1 ppm).
>
> This has two problems:
> 1. Low fees are now a negative signal: defaults actually indicate
> lower reliability, and routing gets tarpitted trying them all.
> 2. There's no meaningful market signal in fees, since you can't
> drop much below 1ppm.
>
> Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
> and seems to have significant usage, so there clearly is market
> tolerance for higher fees.
>
> I am proposing that as of next release of c-lighting, we change defaults
> on new channels to 5000 msat + 500ppm, and I'd like the other
> implementations to join me.
>
> Over time, that should move the noise floor up. I picked 500ppm because
> that's still 1% at 20 hops, so minimally centralizing. I picked 5000
> msat base for less quantifiable reasons.
>
> Here's default fee a rate table in USD (@10k per BTC):
>
> Amount Before After
> 0.1c 0.0100001c 0.05005c
> 1c 0.010001c 0.0505c
> 10c 0.01001c 0.055c
> $1 0.0101c 0.1c
> $10 0.011c 0.55c
> $100 0.02c 5.05c
> $1000 0.11c 50.05c
>
> Thoughts?
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/a52bb47f/attachment.html>;