[Lightning-dev] #zerobasefee

[Matt Corallo]

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