ecurrencyhodler [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-08-13 to 2023-05-25
💬 Posted a total of 6 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:56:40

- reply

📅 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>

2023-06-09 12:55:53

- reply

📅 Original date posted:2019-08-13
📝 Original message:
Hey Rusty. Thanks for your feedback.
>If you publish your node address, Bob can already get this from the
gossip network, or the DNS seed as a last resort (and I expect
implementations to start doing this: I did it manually to buy a
thelightningconference.com ticket recently, for example).
This is a good point and very cool you were able to do that for the
Lightning Conference (hopefully I'll see you there!). Perhaps another
condition should be that if I am a public node and already connected to a
node, the URI is not embedded in the invoice but instead should be gathered
via the gossip network.
But keep in mind that the intended goal of this proposal is for the end
user to have a completely automated experience from invoice payment to
payment reception without having to manage any channels.
>So this proposal is mainly useful where you have no channels at all
(thus cannot advertize your node), or don't want to publish it
generally. And in both those cases, Bob probably doesn't want a channel
with you because it wouldn't be useful for paying anyone else.
I'm not sure I agree.
All nodes who come online for the first time are not connected to any
channels. And even if I hand Bob my URI, I still have to wait for the
channels to be established before I'm able to receive payment. Bob could
open and push a payment to me but this doesn't have to be a requirement.
It could be pushed to a routing node Bob is connected to.
This would also be helpful for non-technical node managers. Rather than
going through the process of finding out a URI and trying to manage their
channels constantly by checking for inbound liquidity, they could simply
create an invoice. If inbound liquidity is lacking, the problem would be
automatically solved for them. This wouldn't be the most efficient way to
obtain inbound liquidity, I think that would only really be more important
for more advanced LN users. Especially because asking someone to open and
commit BTC to you is already a bit of a difficult relationship to negotiate
as expected amount of usage will vary.
Lastly, routing nodes are financially incentivized to do open a channel
with me because they could charge a premium. Thor's instant channel is an
example of this.
On Tue, Aug 13, 2019 at 3:59 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Ecurrencyhodler Blockchains <ecurrencyhodler at gmail.com> writes:
> > 1. Bob wants to send me 100,000 sats.
> > 2. My node just came online and has 0 inbound liquidity.
> > 3. I create an invoice for 100,000 sats. My LN node recognizes I
> have 0
> > inbound liquidity so my wallet also embeds my URI in the invoice.
> > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When
> > it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> > payment.
> > 5. I now own and can spend 100,000 sats instantly.
>
> If you publish your node address, Bob can already get this from the
> gossip network, or the DNS seed as a last resort (and I expect
> implementations to start doing this: I did it manually to buy a
> thelightningconference.com ticket recently, for example).
>
> So this proposal is mainly useful where you have no channels at all
> (thus cannot advertize your node), or don't want to publish it
> generally. And in both those cases, Bob probably doesn't want a channel
> with you because it wouldn't be useful for paying anyone else.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/339ee04d/attachment.html>