Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-15 📝 Original message: Hey Zman and list, I ...
📅 Original date posted:2022-06-15
📝 Original message:
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?
>
> <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
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220615/56c7bcf8/attachment-0001.html>;
📝 Original message:
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?
>
> <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
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220615/56c7bcf8/attachment-0001.html>;