Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-24 📝 Original message: On Fri, Sep 23, 2022 at ...
📅 Original date posted:2022-09-24
📝 Original message:
On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote:
> Some interesting points here. Will try to respond to some of them.
> > pathfinding algorithms which depend on unscalable data collection
> Failed payment attempts are indistinguishable from data collection probing.
Even so, data collection probing is *preferable* -- it can happen out
of band, and doesn't need to cause latency when you're trying to finish
paying for your coffee so you can sit down and get back to doomscrolling.
In general: if you need to know channel capacities to efficiently make
payments, doesn't that fundamentally mean that that information should
be gossipped?
For instance, in a world where everyone's doing rate cards, maybe every
channel is advertising fees at -0.05, +0.01, +0.1, +1.0 bps because that's
just what turns out to be "best". But then when you're trying to find a
route, it becomes critically important to know which channels are at which
capacity quartile. If you're not gossipping that information, then someone
making a payment needs to either probe every plausible path, or subscribe
to an information provider that is regularly probing every channel.
I still think what I wrote in June applies; from [0], what you want
to maintain is a balanced flow over time, not any particular channel
balance -- so collecting less fees at 25% balance than at 75% balance
is generally a false optimisation; and from [1], having fee rate cards
that just depend on time of day/week is probably a much better method of
optimising for what actually matters -- "these are the times my channel
is in high demand in this direction, so fees are high; these are the
times demand is low, so fees are low".
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003624.html
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003627.html
> I like to think that the introduction of negative fees make channel
> balance data a competitive advantage and will actually cause node
> operators to more closely guard their balances / the balance data
> they've collected about peers, which should hopefully reduce the current
> trend of sharing this information with centralized parties.
Having fees depend on the channel balance makes the data a competitive
advantage to the people trying to use the channel; for the channel owner,
the optimal situation is everyone knows the balance, so that more payments
get routed over the channel (because people don't overestimate the fee
rate). That encourages channel owners to broadcast the information,
not keep it private. If they can't broadcast it, that just creates a
market for centralised information brokers...
Cheers,
aj
📝 Original message:
On Fri, Sep 23, 2022 at 03:13:53PM -0500, lisa neigut wrote:
> Some interesting points here. Will try to respond to some of them.
> > pathfinding algorithms which depend on unscalable data collection
> Failed payment attempts are indistinguishable from data collection probing.
Even so, data collection probing is *preferable* -- it can happen out
of band, and doesn't need to cause latency when you're trying to finish
paying for your coffee so you can sit down and get back to doomscrolling.
In general: if you need to know channel capacities to efficiently make
payments, doesn't that fundamentally mean that that information should
be gossipped?
For instance, in a world where everyone's doing rate cards, maybe every
channel is advertising fees at -0.05, +0.01, +0.1, +1.0 bps because that's
just what turns out to be "best". But then when you're trying to find a
route, it becomes critically important to know which channels are at which
capacity quartile. If you're not gossipping that information, then someone
making a payment needs to either probe every plausible path, or subscribe
to an information provider that is regularly probing every channel.
I still think what I wrote in June applies; from [0], what you want
to maintain is a balanced flow over time, not any particular channel
balance -- so collecting less fees at 25% balance than at 75% balance
is generally a false optimisation; and from [1], having fee rate cards
that just depend on time of day/week is probably a much better method of
optimising for what actually matters -- "these are the times my channel
is in high demand in this direction, so fees are high; these are the
times demand is low, so fees are low".
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003624.html
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003627.html
> I like to think that the introduction of negative fees make channel
> balance data a competitive advantage and will actually cause node
> operators to more closely guard their balances / the balance data
> they've collected about peers, which should hopefully reduce the current
> trend of sharing this information with centralized parties.
Having fees depend on the channel balance makes the data a competitive
advantage to the people trying to use the channel; for the channel owner,
the optimal situation is everyone knows the balance, so that more payments
get routed over the channel (because people don't overestimate the fee
rate). That encourages channel owners to broadcast the information,
not keep it private. If they can't broadcast it, that just creates a
market for centralised information brokers...
Cheers,
aj