On 8/25/21 05:50, Anthony Towns wrote:
On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote:
I feel like we're having two very, very different conversations here. On one
hand, you're arguing that the base fee is of marginal use, and that maybe we
can figure out how to average it out such that we can avoid needing it.
I'm not sure about the "we" in that sentence
You and I, and it seems I was very much right :)
I'm saying node operators
shouldn't bother with it, not that lightning software devs shouldn't offer
it as a config option or take it into account when choosing routes. The
only software change that /might/ make sense is changing defaults from
1sat to 0msat, but it seems a bit early for that too, to me.
I think I largely agree, its too early to decide these things and node operators can consider these
issues for themselves.
(I'm assuming comments like "We'll most definitely support #zerobasefee"
[0] just means "you can set it to zero if you like" which seems like a
weird thing to have to say explicitly...)
[0] https://twitter.com/Snyke/status/1418109408438063104
I don't believe so at all, we were definitely having a different conversation from both sides here.
The #zerobasefee movement grew out of, and focuses on, switching to #zerobasefee in order to allow
people to start using routing algorithms in production which ignore all nodes which do *not* have
zero base fee and requiring that to be a routing node. Rusty even made a comment to that effect
recently on a Twitter Spaces, saying that its probably something that could be considered sooner or
later, though I admit it was an off-the-cuff remark so maybe he has a slightly different view when
pressed.
My objection, and it seems like you agree, is that it is much, much too early to start making a
strong assumption of the only fee being a proportional one in deployed routing algorithms.
Also, even if we can maybe do away with the base fee, that still
doesn't mean we should start relying on the lack of any
not-completely-linear-in-HTLC-value fees in our routing algorithms,
I mean, exprimental/research routing algorithms should totally rely
on that if they feel like it? I just don't see any evidence that
anyone's thinking of moving that out of research and into production
until there's feedback from operators and a lot more results from the
research in general...
Maybe, maybe not - my only points on Twitter, and here, have been focused on how more research needs
to happen on proposed routing algorithms and how we can adapt the ideas to other algorithms. A large
part of the impetus for the #zerobasefee movement has been to reduce base fees to allow for a
migration to these experimental algorithms, and, to me, is entirely premature.
No, that's not the topic at hand, at all?
Well, then we were having two different conversations :p
I think I'm arguing for these things:
a) "everyone" should drop their base fee msat from the default,
probably to 0 because that's an easy fixed point that you don't need
to think about again as the price of btc changes, but anything at
or below 10msat would be much more reasonable than 1000msat.
b) if people are concerned about wasting resources forwarding super
small payments for correspondingly super small fees, they should
raise min_htlc_amount from 0 (or 1000) to compensate, instead of
raising their base fee.
:shrug: dunno. some people pay on-chain fees to route tiny payments to Muun wallets and seem fine
with it.
c) software should dynamically increase min_htlc_amount as the
number of available htlc slots decreases, as a DoS mitigation measure.
(presuming this is a temporary increase, probably this wouldn't
be gossiped, and possibly not even communicated to the channel
counterparty -- just a way of immediately rejecting htlcs? I think
if something along these lines were implemented, (b) would almost
never be necessary)
This sounds like a cool idea. We shipped something highly related that almost accomplishes this on
accident in LDK [1] focusing on exposure to small-value HTLCs and limiting that to ensure we don't
send all our money to miners.
More dynamic limits in lightning sounds like the right direction to me! Also dynamic fees, also
dynamic....
d) the default base fee should be changed to 0, 1, or 10msat instead
of 1000msat
e) trivially: (I don't think anyone's saying otherwise)
- deploying new algorithms in production should only be done with
a lot of care
There is *so* much debate around this point in the lightning world these days. This is just another
flavor of it.
Matt
[1] https://github.com/rust-bitcoin/rust-lightning/pull/1009
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
