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. > 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. 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. 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! : https://github.com/lightningnetwork/lnd/pull/3462 : https://github.com/ksedgwic/lndtool/blob/graphstats/lightning-fee-market.pdf : https://blog.lightning.engineering/posts/2019/08/15/routing-quide-1.html On Thu, Oct 10, 2019 at 7:50 PM Rusty Russell <ru...@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 > Lightningfirstname.lastname@example.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev