ecurrencyhodler [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-12 📝 Original message: Good morning Rusty. To ...
📅 Original date posted:2019-10-12
📝 Original message:
Good morning Rusty.
To add to roasbeef's point, I don't think lightningpowerusers.com is a good
indicator for market tolerance for higher fees either. It's highly
connected and does a lot of routing because Pierre has on boarded many
users through the node launcher. That means most of these users aren't
power users and therefore aren't technically skilled enough or aware of how
to find a cheaper route.
I agree with the sentiment that the network is still too young to derive
any meaningful observations around a routing fee market. This will become
clearer though as more routing tools and analytics are created for routing
node operators as well wallet users.
On Fri, Oct 11, 2019 at 6:34 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> 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
>>
> _______________________________________________
> 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/20191012/a54966e1/attachment.html>;
📝 Original message:
Good morning Rusty.
To add to roasbeef's point, I don't think lightningpowerusers.com is a good
indicator for market tolerance for higher fees either. It's highly
connected and does a lot of routing because Pierre has on boarded many
users through the node launcher. That means most of these users aren't
power users and therefore aren't technically skilled enough or aware of how
to find a cheaper route.
I agree with the sentiment that the network is still too young to derive
any meaningful observations around a routing fee market. This will become
clearer though as more routing tools and analytics are created for routing
node operators as well wallet users.
On Fri, Oct 11, 2019 at 6:34 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> 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
>>
> _______________________________________________
> 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/20191012/a54966e1/attachment.html>;