Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-16 📝 Original message: On Sun, Aug 15, 2021 at ...
📅 Original date posted:2021-08-16
📝 Original message:
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
> On 8/15/21 22:02, Anthony Towns wrote:
> > > In
> > > one particular class of applicable routing algorithms you could use for
> > > lightning routing having a base fee makes the algorithm intractably slow,
> > I don't think of that as the problem, but rather as the base fee having
> > a multiplicative effect as you split payments.
> Yes, matching the real-world costs of forwarding an HTLC.
Actually, no, not at all.
The base+proportional fees paid only on success roughly match the *value*
of forwarding an HTLC, they don't match the costs particularly well
at all.
Why not? Because the costs are incurred on failed HTLCs as well, and
also depend on the time a HTLC lasts, and also vary heavily depending
on how many other simultaneous HTLCs there are.
> Yes. You have to pay the cost of a node. If we're really worried about this,
> we should be talking about upfront fees and/or refunds on HTLC fulfillment,
> not removing the fees entirely.
(I don't believe either of those are the right approach, but based on
previous discussions, I don't think anyone's going to realise I'm right
until I implement it and prove it, so *shrug*)
> > Being denominated in sats, the base fee also changes in value as the
> > bitcoin price changes -- c-lightning dropped the base fee to 1sat (from
> > 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x
> > since then, and it seems unlikely the fixed costs of a successful HTLC
> > payment have likewise increased 4x. Proportional fees deal with this
> > factor automatically, of course.
> This isn't a protocol issue, implementations can automate this without issue.
I don't think anyone's proposing the protocol be changed; just that node
operators set an option to a particular value?
Well, except that Lisa's maybe proposing that 0 not be allowed, and a
value >= 0.001 sat be required? I'm not quite sure.
> > > There's real cost to distorting the fee structures on the network away from
> > > the costs of node operators,
> > That's precisely what the base fee is already doing.
> Huh? For values much smaller than a node's liquidity, the cost for nodes is
> (mostly) a function of HTLCs, not the value.
Yes, the cost for nodes is a function of the requests that come in, not
how many succeed. The fees are proportional to how many succeed, which
is at best a distorted reflection of the number of requests that come in.
> The cost to nodes is largely [...]
The cost to nodes is almost entirely the opportunity cost of not being
able to accept other txs that would come in afterwards and would pay
higher fees.
And all those costs can be captured equally well (or badly) by just
setting a proportional fee and a minimum payment value. I don't know why
you keep ignoring that point.
> so I'd argue for many HTLCs forwarded
> today per-payment costs mirror the cost to a node much, much, much, much
> better than some proportional fees?
You're talking yourself into a *really* broken business model there.
> > Additionally, I don't think HTLC slot usage needs to be kept as a
> > limitation after we switch to eltoo;
> The HTLC slot limit is to keep transactions broadcastable. I don't see why
> this would change, you still get an output for each HTLC on the latest
> commitment in eltoo, AFAIU.
eltoo gives us the ability to have channel factories, where we divide
the overall factory balance amongst different channels, all updated
off-chain. It seems likely we'll want to do factories from day one,
so that we don't implicitly limit either the lifetime of the channel
or its update rate (>1 update/sec ~= <4 year lifetime otherwise if I
did the maths right). Once we're doing factories, if we have more than
however many htlcs for a channel, we can re-divide the factory balance
and add a new channel. If the limit is 500 HTLCs per tx, you'd have to
amortize 0.2% of the new tx across each HTLC, in addition to the cost
of the HTLC itself, but that seems trivial.
> > and in the meantime, I think it can
> > be better managed via adjusting the min_htlc_amount -- at least for the
> > scenario where problems are being caused by legitimate payment attempts,
> > which is also the only place base fee can help.
> Sure, we could also shift towards upfront fees or similar solutions,
Upfront fees seem extremely vulnerable to attacks, and are certainly a
(pretty large) protocol change.
> > > Instead, we should investigate how we can
> > > apply the ideas here with the more complicated fee structures we have.
> > Fee structures should be *simple* not complicated.
> > I mean, it's kind of great that we started off complicated -- if it
> > turns out base fee isn't necessary, it's easy to just set it to zero;
> > if we didn't have it, but needed it, it would be much more annoying to
> > add it in later.
> Fee structures should also match reality, and allow node operators
> sufficient flexibility to capture their costs. I think we have a design that
> does so quite well - its pretty simple, there's only two knobs, but the two
> knobs capture exactly the two broad categories of costs a node operator has.
I don't know how you can think these "exactly" capture node operators'
costs. They're missing the time factor, and don't capture any of the
costs due to failed payments.
> Sure, the great thing about today is because the protocol exposes decent
> knobs operators can tune
Knobs are great for experimenting; but they're also something to work
at reducing once the experiments have come up with some results. I
think #zerobasefee is more in the experiment stage: "hey, this seems
like a great idea, let's set this knob to zero and focus on these other
ones instead".
> > For an experimental plugin that aggressively splits payments up, I think
> > either ignoring channels with >0 base fee entirely, or deciding that
> > you're happy to spend a total of X sats on base fees, and then ignoring
> > channels whose base fee is greater than X/paths/path-length sats is fine.
> Sure, experimental plugins can do whatever they want!
Is there any reason to think any of this would be something other than
node configuration options and experimental plugins any time soon?
(By "any time soon" I mean, I could see software defaults changing if
over 50% of the network deliberately switched to zero base fees and found
it worked fine; and I could see deprecating non-zero fees if that ended
up with 90% of the network on zero base fees, no good reasons for node
operators wanting to stick with running non-zero base fees, and the
experimental algos that relied on zero base fees being significantly
easier to maintain or faster/better)
> > But long term, I also think that the base fee is an entirely unhelpful
> > complication that will eventually just be hardcoded to zero by everyone,
> > and eventually channels that propose non-zero base fees won't even be
> > gossiped. I don't expect that to happen any time soon though.
> I very strongly disagree, as discussed, and am left highly dubious
> that it is a practical complication in any case.
That's okay! Long term predictions would be pretty boring if everyone
agreed with them.
Cheers,
aj
📝 Original message:
On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote:
> On 8/15/21 22:02, Anthony Towns wrote:
> > > In
> > > one particular class of applicable routing algorithms you could use for
> > > lightning routing having a base fee makes the algorithm intractably slow,
> > I don't think of that as the problem, but rather as the base fee having
> > a multiplicative effect as you split payments.
> Yes, matching the real-world costs of forwarding an HTLC.
Actually, no, not at all.
The base+proportional fees paid only on success roughly match the *value*
of forwarding an HTLC, they don't match the costs particularly well
at all.
Why not? Because the costs are incurred on failed HTLCs as well, and
also depend on the time a HTLC lasts, and also vary heavily depending
on how many other simultaneous HTLCs there are.
> Yes. You have to pay the cost of a node. If we're really worried about this,
> we should be talking about upfront fees and/or refunds on HTLC fulfillment,
> not removing the fees entirely.
(I don't believe either of those are the right approach, but based on
previous discussions, I don't think anyone's going to realise I'm right
until I implement it and prove it, so *shrug*)
> > Being denominated in sats, the base fee also changes in value as the
> > bitcoin price changes -- c-lightning dropped the base fee to 1sat (from
> > 546 sat!) in Jan 2018, but the value of 1sat has increased about 4x
> > since then, and it seems unlikely the fixed costs of a successful HTLC
> > payment have likewise increased 4x. Proportional fees deal with this
> > factor automatically, of course.
> This isn't a protocol issue, implementations can automate this without issue.
I don't think anyone's proposing the protocol be changed; just that node
operators set an option to a particular value?
Well, except that Lisa's maybe proposing that 0 not be allowed, and a
value >= 0.001 sat be required? I'm not quite sure.
> > > There's real cost to distorting the fee structures on the network away from
> > > the costs of node operators,
> > That's precisely what the base fee is already doing.
> Huh? For values much smaller than a node's liquidity, the cost for nodes is
> (mostly) a function of HTLCs, not the value.
Yes, the cost for nodes is a function of the requests that come in, not
how many succeed. The fees are proportional to how many succeed, which
is at best a distorted reflection of the number of requests that come in.
> The cost to nodes is largely [...]
The cost to nodes is almost entirely the opportunity cost of not being
able to accept other txs that would come in afterwards and would pay
higher fees.
And all those costs can be captured equally well (or badly) by just
setting a proportional fee and a minimum payment value. I don't know why
you keep ignoring that point.
> so I'd argue for many HTLCs forwarded
> today per-payment costs mirror the cost to a node much, much, much, much
> better than some proportional fees?
You're talking yourself into a *really* broken business model there.
> > Additionally, I don't think HTLC slot usage needs to be kept as a
> > limitation after we switch to eltoo;
> The HTLC slot limit is to keep transactions broadcastable. I don't see why
> this would change, you still get an output for each HTLC on the latest
> commitment in eltoo, AFAIU.
eltoo gives us the ability to have channel factories, where we divide
the overall factory balance amongst different channels, all updated
off-chain. It seems likely we'll want to do factories from day one,
so that we don't implicitly limit either the lifetime of the channel
or its update rate (>1 update/sec ~= <4 year lifetime otherwise if I
did the maths right). Once we're doing factories, if we have more than
however many htlcs for a channel, we can re-divide the factory balance
and add a new channel. If the limit is 500 HTLCs per tx, you'd have to
amortize 0.2% of the new tx across each HTLC, in addition to the cost
of the HTLC itself, but that seems trivial.
> > and in the meantime, I think it can
> > be better managed via adjusting the min_htlc_amount -- at least for the
> > scenario where problems are being caused by legitimate payment attempts,
> > which is also the only place base fee can help.
> Sure, we could also shift towards upfront fees or similar solutions,
Upfront fees seem extremely vulnerable to attacks, and are certainly a
(pretty large) protocol change.
> > > Instead, we should investigate how we can
> > > apply the ideas here with the more complicated fee structures we have.
> > Fee structures should be *simple* not complicated.
> > I mean, it's kind of great that we started off complicated -- if it
> > turns out base fee isn't necessary, it's easy to just set it to zero;
> > if we didn't have it, but needed it, it would be much more annoying to
> > add it in later.
> Fee structures should also match reality, and allow node operators
> sufficient flexibility to capture their costs. I think we have a design that
> does so quite well - its pretty simple, there's only two knobs, but the two
> knobs capture exactly the two broad categories of costs a node operator has.
I don't know how you can think these "exactly" capture node operators'
costs. They're missing the time factor, and don't capture any of the
costs due to failed payments.
> Sure, the great thing about today is because the protocol exposes decent
> knobs operators can tune
Knobs are great for experimenting; but they're also something to work
at reducing once the experiments have come up with some results. I
think #zerobasefee is more in the experiment stage: "hey, this seems
like a great idea, let's set this knob to zero and focus on these other
ones instead".
> > For an experimental plugin that aggressively splits payments up, I think
> > either ignoring channels with >0 base fee entirely, or deciding that
> > you're happy to spend a total of X sats on base fees, and then ignoring
> > channels whose base fee is greater than X/paths/path-length sats is fine.
> Sure, experimental plugins can do whatever they want!
Is there any reason to think any of this would be something other than
node configuration options and experimental plugins any time soon?
(By "any time soon" I mean, I could see software defaults changing if
over 50% of the network deliberately switched to zero base fees and found
it worked fine; and I could see deprecating non-zero fees if that ended
up with 90% of the network on zero base fees, no good reasons for node
operators wanting to stick with running non-zero base fees, and the
experimental algos that relied on zero base fees being significantly
easier to maintain or faster/better)
> > But long term, I also think that the base fee is an entirely unhelpful
> > complication that will eventually just be hardcoded to zero by everyone,
> > and eventually channels that propose non-zero base fees won't even be
> > gossiped. I don't expect that to happen any time soon though.
> I very strongly disagree, as discussed, and am left highly dubious
> that it is a practical complication in any case.
That's okay! Long term predictions would be pretty boring if everyone
agreed with them.
Cheers,
aj