From bastien at acinq.fr Wed Jun 15 08:09:13 2022 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Wed, 15 Jun 2022 10:09:13 +0200 Subject: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary In-Reply-To: References: Message-ID: Hey Zman and list, I don't think waxwing's proposal will help us for private gossip. The rate-limiting it provides doesn't seem to be enough in our case. The proposal rate-limits token issuance to once every N blocks where N is the age of the utxo to which we prove ownership of. Once the token is issued and verified, the attacker can spend that utxo, and after N blocks he's able to get a new token with this new utxo. That is a good enough rate-limit for some scenarios, but in our case it means that every N blocks people are able to double the capacity they advertise without actually having more funds. We can probably borrow ideas from this proposal, but OTOH I don't see how to apply it to lightning gossip, what we want isn't really rate limiting, we want a stronger link between advertised capacity and real on-chain capacity. Cheers, Bastien Le mer. 15 juin 2022 ? 00:01, ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a ?crit : > > > ## Lightning Gossip > > > > # Gossip V2: Now Or Later? > > > > > 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. > > > > > # 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: