Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-25 📝 Original message: On Tue, Aug 24, 2021 at ...
📅 Original date posted:2021-08-25
📝 Original message:
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 -- 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'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
> On
> the other hand, I'm arguing that, yes, maybe you can, but ideally you
> wouldn't have to, because its still pretty nice to capture those costs
> sometimes.
I don't really think it captures costs at all, but I do agree it could
be nice (at least in theory) to have it available since then you might
be able to better optimise your fee income based on whatever demand
happens to be. That's to increase profits, not match costs though, and
I'm not convinced the theory will play out in practice presuming AMP is
often useful/necessary.
> 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...
> as maybe
> we'll want to do upfront payments or some other kind of anti-DoS payment in
> the future to solve the gaping, glaring, giant DoS hole that is HTLCs taking
> forever to time out.
Until we've got an even vaguely workable scheme for that, I don't
think it's relevant to consider. (If my preferred scheme turns out
to be workable, I don't think it needs to be taken into account when
(multi)pathfinding at all)
> I'm not even sure that you're trying to argue, here, that we should start
> making key assumptions about the only fee being a proportional one in our
> routing algorithms, but that is what the topic at hand is, so I can't help
> but assume you are?
No, that's not the topic at hand, at all?
I mean, it's related, and interesting to talk about, but it's a digression
into "wild ideas that might happen in the future", not the topic... I
don't think anyone's currently advocating for node software to work that
way? (I do think having many/most channels have a zero base fee will make
multipath routing algos work better even when they *don't* assume the
base fee is zero)
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.
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)
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)
- 0 base fee should be a supported config option
- research/experimental routing algorithms are great and should
be encouraged
- deploying new algorithms in production should only be done with
a lot of care
- changing the protocol should only be done with even more care
- proportional fees should be rounded up to the next msat and never
rounded down to 0
- research/experiments on charging for holding htlcs open should
continue (likewise research on other DoS prevention measures)
I'm not super sure about (c) or (d), and the "everyone" in (a) could
easily not really be everyone.
> If you disagree with the above characterization I'm happy to go line-by-line
> tit-for-tat, but usually those kinds of tirades aren't exactly useful and
> end up being more about semantics than the thrust of the argument.
Thanks for the lack of a tirade :)
Cheers,
aj
📝 Original message:
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 -- 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'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
> On
> the other hand, I'm arguing that, yes, maybe you can, but ideally you
> wouldn't have to, because its still pretty nice to capture those costs
> sometimes.
I don't really think it captures costs at all, but I do agree it could
be nice (at least in theory) to have it available since then you might
be able to better optimise your fee income based on whatever demand
happens to be. That's to increase profits, not match costs though, and
I'm not convinced the theory will play out in practice presuming AMP is
often useful/necessary.
> 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...
> as maybe
> we'll want to do upfront payments or some other kind of anti-DoS payment in
> the future to solve the gaping, glaring, giant DoS hole that is HTLCs taking
> forever to time out.
Until we've got an even vaguely workable scheme for that, I don't
think it's relevant to consider. (If my preferred scheme turns out
to be workable, I don't think it needs to be taken into account when
(multi)pathfinding at all)
> I'm not even sure that you're trying to argue, here, that we should start
> making key assumptions about the only fee being a proportional one in our
> routing algorithms, but that is what the topic at hand is, so I can't help
> but assume you are?
No, that's not the topic at hand, at all?
I mean, it's related, and interesting to talk about, but it's a digression
into "wild ideas that might happen in the future", not the topic... I
don't think anyone's currently advocating for node software to work that
way? (I do think having many/most channels have a zero base fee will make
multipath routing algos work better even when they *don't* assume the
base fee is zero)
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.
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)
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)
- 0 base fee should be a supported config option
- research/experimental routing algorithms are great and should
be encouraged
- deploying new algorithms in production should only be done with
a lot of care
- changing the protocol should only be done with even more care
- proportional fees should be rounded up to the next msat and never
rounded down to 0
- research/experiments on charging for holding htlcs open should
continue (likewise research on other DoS prevention measures)
I'm not super sure about (c) or (d), and the "everyone" in (a) could
easily not really be everyone.
> If you disagree with the above characterization I'm happy to go line-by-line
> tit-for-tat, but usually those kinds of tirades aren't exactly useful and
> end up being more about semantics than the thrust of the argument.
Thanks for the lack of a tirade :)
Cheers,
aj