ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-14 📝 Original message: > ## Lightning Gossip > > ...

📅 Original date posted:2022-06-14
📝 Original message:
> ## Lightning Gossip
>
> # Gossip V2: Now Or Later?

<snip>

> A proposal for the "re-design the entire thing" was floated in the past by
> Rusty [6]. It does away with the strict coupling of channels to channel
> announcements, and instead moves them to the _node_ level. Each node would
> then advertise the set of "outputs" they have control of, which would then
> be mapped to the total capacity of a node, without requiring that these
> outputs self identify themselves on-chain as Lightning Channels. This also
> opens up the door to different, potentially more privacy preserving
> proofs-of-channel-ownership (something something zkp).

waxwing recently posted something interesting over in bitcoin-dev, which seems to match the proof-of-channel-ownereship.

https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f

I confess to not understanding the mathy bits but it seems to me, naively, that the feature set waxwing points out match well with the issues we want to have:

* We want to rate-limit gossip somehow.
* We want to keep the mapping of UTXOs to channels private.

It requires a global network that cuts across all uses of the same mechanism (similar to defiads, but more private --- basically this means that it cannot be just Lightning which uses this mechanism, at least to acquire tokens-to-broadcast-my-channels) to prevent a UTXO from being reused across services, a property I believe is vital to the expected spam-resistance.

> # Friend-of-a-friend Balance Sharing & Probing
>
> A presentation was given on friend-of-a-friend balance sharing [16]. The
> high level idea is that if we share _some_ information within a local
> radius, then this gives the sender more information to choose a path that's
> potentially more reliable. The tradeoff here ofc is that nodes will be
> giving away more information that can potentially be used to ascertain
> payment flows. In an attempt to minimize the amount of information shared,
> the presenter proposed that just 2 bits of information be shared. Some
> initial simulations showed that sharing local information actually performed
> better than sharing global information (?). Some were puzzled w.r.t how
> that's possible, but assuming the slides+methods are published others can
> dig further into the model/parameter used to signal the inclusion.
>
> Arguably, information like this is already available via probing, so one
> line of thinking is something like: "why not just share _some_ of it" that
> may actually lead to less internal failures? This is related to a sort of
> tension between probing as a tool to increase payment reliability and also
> as a tool to degrade privacy in the network. On the other hand, others
> argued that probing provides natural cover traffic, since they actually
> _are_ payments, though they may not be intended to succeed.
>
> On the topic of channel probing, a sort of makeshift protocol was devised to
> make it harder in practice, sacrificing too much on the axis of payment
> reliability. At a high level it proposes that:
>
> * nodes more diligently set both their max_htlc amount, as well as the
> max_htlc_value_in_flight amount
>
> * a 50ms (or select other value) timer should be used when sending out
> commitment signatures, independent of HTLC arrival
>
> * nodes leverage the max_htlc value to set a false ceiling on the max in
> flight parameter
>
> * for each HTLC sent/forwarded, select 2 other channels at random and
> reduce the "fake" in-flight ceiling for a period of time
>
> Some more details still need to be worked out, but some felt that this would
> kick start more research into this area, and also make balance mapping
> _slightly_ more difficult. From afar, it may be the case that achieving
> balance privacy while also achieving acceptable levels of payment
> reliability might be at odds with each other.

A point that was brought up is that nodes can lie about their capacity, and there would be no way to counteract this.

Even given the above, it would be trivial for a lying node to randomly lie about their `max_htlc` to still be noticed by nodes who try to filter out nodes who do not update their `max_htlc`s.
(maximal lying is to always say 50% of your capacity is in `max_htlc`, your node can lie by setting `max_htlc` from 35%->65%, you can coordinate this with another lying peer node too by use of an odd message number to set up the lying protocol so both of you can lie about the channel capacity consistently)

I think your best bet is really to utilize feerates, as lying with those is expected to lead to economic loss.

<snip>

> # Node Fee Optimization & Fee Rate Cards
>
> Over the past few years, a common thread we've seen across successful
> routing nodes is dynamic fee setting as a way to encourage/discourage
> traffic. A routing nodes can utilize the set of fees of a channel to either
> make it too expensive for other nodes to route through (it's already
> depleted don't try unless you'll give be 10 mil sats, which no one would) or
> very cheap, which'll incentivize flows in the other direction. If all nodes
> are constantly sending out updates of this nature, then it can generate a
> lot of traffic, and also sort of leak more balance information overtime
> (which some nodes are already doing: using fees/max_htlc to communicate
> available balances).
>
> One attendee proposed allowing nodes to express a sort of fee gradient via a
> static curve/bucket/function, instead of dynamically communicating what the
> latest state of the fee+liquidity distribution looks like. A possible
> manifestation could be a series of buckets, each of which with varying fee
> rates. If your payment consumes 50% of channel balance, then you pay this
> rate, otherwise if it's 5% you pay this rate, etc, etc.

I think this is not what was actually proposed?

As I understood it, the percent range is not how much the payment consumes of the channel balance but instead the percent range is the probability-of-success given a uniform distribution of channel balance.

For instance if the current channel balance is currently 67%, then the forwarding node will succeed all payments that pay a fee from the 33% fee card or higher, otherwise fail the payment with "not enough fees".

The intent is that payers will treat 100% - fee_card_percent as the probability-of-failure of that channel, and can select which fee card maximizes both its probability-of-failure and max-fee in some kind of reasonable exchange rate.

Regards,
ZmnSCPxj