lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-23 📝 Original message: Some interesting points ...
📅 Original date posted:2022-09-23
📝 Original message:
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.
I don't think it's realistic to think that payments are going to stop
failing in
an environment where we continue to prioritize privacy of channel balances.
I think I pretty nicely illustrated the benefits of using payment bands in
my original
post wrt to a balance between "probe-ability" and some obfuscation of
balance, along
with a net reduction in the bandwidth consumption required to get this
basically
required information for payment success.
Rene Pickhardt has a less private, less costly, more granular, smaller scope
proposal for sharing channel balances w/ directly connected peers; I think
this is worth investigating independently of this proposal.
> depend on the centralized entities performing the data collection
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.
Note that with the present protocol design, the network incentives are such
that centralized efforts to collect exact balance data already exist. So
moving to this design has the potential to reduce the incentive to
participate
in the data collection, at the very least it does not make it worse than
current.
> this costs Alice nothing extra but reduces network capacity by consuming
> HTLC slots for her, Bob, and every other forwarding channel.
the network already limits the size of htlcs that are allowable with the
htlc_maximum_msat, which I understand is typically set at a rate below 1/4
of channel capacity (citation needed). Which is to say that the large
consumption of a channel in a single HTLC is currently relatively
prohibited.
It's likely this proposed change would actually encourage operators to set
their htlc_maximum_msat higher, now that there's a direct financial cost
tied to larger channel bandwidth consumption.
Great questions! Hope that gives a better picture of the current landscape.
Also h/t to ZmnSCPxj for the excellent "four parallel channels" analogy,
this is
a really elegant way to think about the proposal.
On Thu, Sep 22, 2022 at 11:39 PM David A. Harding <dave at dtrt.org> wrote:
> On 2022-09-22 16:08, ZmnSCPxj wrote:
> > Basically, you can model a rate card as four separate channels between
> > the same two nodes, with different costs each.
> > If the path at the lowest cost fails, you just try at another route
> > that may have more hops but lower effective cost, or else try the same
> > channel at a higher cost.
>
> That's a very easy to understand explanation of how to use the system,
> thanks!
>
> > If your concern is valid, one wonders why it would not already exist
> > now in the current network where try-and-try-again is the standard
> > overall algorithm for payments.
>
> My concern is about pathfinding algorithms which depend on unscalable
> data collection (e.g. frequent whole network probing). If such an
> algorithm performs much better than those algorithms which depend on
> scalable data collection (e.g. receiving gossip), then the network may
> grow to depend on the centralized entities performing the data
> collection to the detriment of its robustness and its participants'
> independence.
>
> Try-and-try-another-path is somewhat problematic in this regard since,
> even with no additional action like probing, entities which send many
> payments will likely perform significantly better than entities which
> send few payments owing to the high-frequency spenders gaining more
> knowledge about which channels and amounts recently worked or did not.
> It seems to me that a more idealized system would only rarely have
> forwarding failures so that high frequency spenders wouldn't receive
> much more information than low frequency spenders. To that regard, fee
> ratecards feels like a small step in the wrong direction because
> modeling one channel as four separate channels further normalizes
> failure and so further moves the system towards centralized dependency.
> That said, as you mentioned in a previous post[1], I agree ratecards is
> better than frequently issuing new channel updates with modified fees.
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220923/07d0d25b/attachment.html>;
📝 Original message:
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.
I don't think it's realistic to think that payments are going to stop
failing in
an environment where we continue to prioritize privacy of channel balances.
I think I pretty nicely illustrated the benefits of using payment bands in
my original
post wrt to a balance between "probe-ability" and some obfuscation of
balance, along
with a net reduction in the bandwidth consumption required to get this
basically
required information for payment success.
Rene Pickhardt has a less private, less costly, more granular, smaller scope
proposal for sharing channel balances w/ directly connected peers; I think
this is worth investigating independently of this proposal.
> depend on the centralized entities performing the data collection
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.
Note that with the present protocol design, the network incentives are such
that centralized efforts to collect exact balance data already exist. So
moving to this design has the potential to reduce the incentive to
participate
in the data collection, at the very least it does not make it worse than
current.
> this costs Alice nothing extra but reduces network capacity by consuming
> HTLC slots for her, Bob, and every other forwarding channel.
the network already limits the size of htlcs that are allowable with the
htlc_maximum_msat, which I understand is typically set at a rate below 1/4
of channel capacity (citation needed). Which is to say that the large
consumption of a channel in a single HTLC is currently relatively
prohibited.
It's likely this proposed change would actually encourage operators to set
their htlc_maximum_msat higher, now that there's a direct financial cost
tied to larger channel bandwidth consumption.
Great questions! Hope that gives a better picture of the current landscape.
Also h/t to ZmnSCPxj for the excellent "four parallel channels" analogy,
this is
a really elegant way to think about the proposal.
On Thu, Sep 22, 2022 at 11:39 PM David A. Harding <dave at dtrt.org> wrote:
> On 2022-09-22 16:08, ZmnSCPxj wrote:
> > Basically, you can model a rate card as four separate channels between
> > the same two nodes, with different costs each.
> > If the path at the lowest cost fails, you just try at another route
> > that may have more hops but lower effective cost, or else try the same
> > channel at a higher cost.
>
> That's a very easy to understand explanation of how to use the system,
> thanks!
>
> > If your concern is valid, one wonders why it would not already exist
> > now in the current network where try-and-try-again is the standard
> > overall algorithm for payments.
>
> My concern is about pathfinding algorithms which depend on unscalable
> data collection (e.g. frequent whole network probing). If such an
> algorithm performs much better than those algorithms which depend on
> scalable data collection (e.g. receiving gossip), then the network may
> grow to depend on the centralized entities performing the data
> collection to the detriment of its robustness and its participants'
> independence.
>
> Try-and-try-another-path is somewhat problematic in this regard since,
> even with no additional action like probing, entities which send many
> payments will likely perform significantly better than entities which
> send few payments owing to the high-frequency spenders gaining more
> knowledge about which channels and amounts recently worked or did not.
> It seems to me that a more idealized system would only rarely have
> forwarding failures so that high frequency spenders wouldn't receive
> much more information than low frequency spenders. To that regard, fee
> ratecards feels like a small step in the wrong direction because
> modeling one channel as four separate channels further normalizes
> failure and so further moves the system towards centralized dependency.
> That said, as you mentioned in a previous post[1], I agree ratecards is
> better than frequently issuing new channel updates with modified fees.
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003598.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220923/07d0d25b/attachment.html>;