📅 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>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:06:14
in reply to nevent1q…f0nm
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:06:14Event JSON
{
"id": "6fcaa7ddd07f27dcba07629632530efaa7abf5aa6205d025e4a605f0c24ed045",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315974,
"kind": 1,
"tags": [
[
"e",
"dc50ebb4a33ebb68559db83f1f909a9de4df76c851710dee0b49ae8b2ad5f61f",
"",
"root"
],
[
"e",
"d1c6e909d097595cea8df56d9d7263fc1098fc7dd6232e44553d5c527e34de69",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-06-15\n📝 Original message:\nHey Zman and list,\n\nI don't think waxwing's proposal will help us for private gossip.\nThe rate-limiting it provides doesn't seem to be enough in our case.\nThe proposal rate-limits token issuance to once every N blocks where\nN is the age of the utxo to which we prove ownership of. Once the token\nis issued and verified, the attacker can spend that utxo, and after N\nblocks he's able to get a new token with this new utxo.\n\nThat is a good enough rate-limit for some scenarios, but in our case\nit means that every N blocks people are able to double the capacity\nthey advertise without actually having more funds.\n\nWe can probably borrow ideas from this proposal, but OTOH I don't\nsee how to apply it to lightning gossip, what we want isn't really rate\nlimiting, we want a stronger link between advertised capacity and\nreal on-chain capacity.\n\nCheers,\nBastien\n\nLe mer. 15 juin 2022 à 00:01, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e\n\u003e \u003e ## Lightning Gossip\n\u003e \u003e\n\u003e \u003e # Gossip V2: Now Or Later?\n\u003e\n\u003e \u003csnip\u003e\n\u003e\n\u003e \u003e A proposal for the \"re-design the entire thing\" was floated in the past\n\u003e by\n\u003e \u003e Rusty [6]. It does away with the strict coupling of channels to channel\n\u003e \u003e announcements, and instead moves them to the _node_ level. Each node\n\u003e would\n\u003e \u003e then advertise the set of \"outputs\" they have control of, which would\n\u003e then\n\u003e \u003e be mapped to the total capacity of a node, without requiring that these\n\u003e \u003e outputs self identify themselves on-chain as Lightning Channels. This\n\u003e also\n\u003e \u003e opens up the door to different, potentially more privacy preserving\n\u003e \u003e proofs-of-channel-ownership (something something zkp).\n\u003e\n\u003e waxwing recently posted something interesting over in bitcoin-dev, which\n\u003e seems to match the proof-of-channel-ownereship.\n\u003e\n\u003e https://gist.github.com/AdamISZ/51349418be08be22aa2b4b469e3be92f\n\u003e\n\u003e I confess to not understanding the mathy bits but it seems to me, naively,\n\u003e that the feature set waxwing points out match well with the issues we want\n\u003e to have:\n\u003e\n\u003e * We want to rate-limit gossip somehow.\n\u003e * We want to keep the mapping of UTXOs to channels private.\n\u003e\n\u003e It requires a global network that cuts across all uses of the same\n\u003e mechanism (similar to defiads, but more private --- basically this means\n\u003e that it cannot be just Lightning which uses this mechanism, at least to\n\u003e acquire tokens-to-broadcast-my-channels) to prevent a UTXO from being\n\u003e reused across services, a property I believe is vital to the expected\n\u003e spam-resistance.\n\u003e\n\u003e \u003e # Friend-of-a-friend Balance Sharing \u0026 Probing\n\u003e \u003e\n\u003e \u003e A presentation was given on friend-of-a-friend balance sharing [16]. The\n\u003e \u003e high level idea is that if we share _some_ information within a local\n\u003e \u003e radius, then this gives the sender more information to choose a path\n\u003e that's\n\u003e \u003e potentially more reliable. The tradeoff here ofc is that nodes will be\n\u003e \u003e giving away more information that can potentially be used to ascertain\n\u003e \u003e payment flows. In an attempt to minimize the amount of information\n\u003e shared,\n\u003e \u003e the presenter proposed that just 2 bits of information be shared. Some\n\u003e \u003e initial simulations showed that sharing local information actually\n\u003e performed\n\u003e \u003e better than sharing global information (?). Some were puzzled w.r.t how\n\u003e \u003e that's possible, but assuming the slides+methods are published others can\n\u003e \u003e dig further into the model/parameter used to signal the inclusion.\n\u003e \u003e\n\u003e \u003e Arguably, information like this is already available via probing, so one\n\u003e \u003e line of thinking is something like: \"why not just share _some_ of it\"\n\u003e that\n\u003e \u003e may actually lead to less internal failures? This is related to a sort of\n\u003e \u003e tension between probing as a tool to increase payment reliability and\n\u003e also\n\u003e \u003e as a tool to degrade privacy in the network. On the other hand, others\n\u003e \u003e argued that probing provides natural cover traffic, since they actually\n\u003e \u003e _are_ payments, though they may not be intended to succeed.\n\u003e \u003e\n\u003e \u003e On the topic of channel probing, a sort of makeshift protocol was\n\u003e devised to\n\u003e \u003e make it harder in practice, sacrificing too much on the axis of payment\n\u003e \u003e reliability. At a high level it proposes that:\n\u003e \u003e\n\u003e \u003e * nodes more diligently set both their max_htlc amount, as well as the\n\u003e \u003e max_htlc_value_in_flight amount\n\u003e \u003e\n\u003e \u003e * a 50ms (or select other value) timer should be used when sending out\n\u003e \u003e commitment signatures, independent of HTLC arrival\n\u003e \u003e\n\u003e \u003e * nodes leverage the max_htlc value to set a false ceiling on the max in\n\u003e \u003e flight parameter\n\u003e \u003e\n\u003e \u003e * for each HTLC sent/forwarded, select 2 other channels at random and\n\u003e \u003e reduce the \"fake\" in-flight ceiling for a period of time\n\u003e \u003e\n\u003e \u003e Some more details still need to be worked out, but some felt that this\n\u003e would\n\u003e \u003e kick start more research into this area, and also make balance mapping\n\u003e \u003e _slightly_ more difficult. From afar, it may be the case that achieving\n\u003e \u003e balance privacy while also achieving acceptable levels of payment\n\u003e \u003e reliability might be at odds with each other.\n\u003e\n\u003e A point that was brought up is that nodes can lie about their capacity,\n\u003e and there would be no way to counteract this.\n\u003e\n\u003e Even given the above, it would be trivial for a lying node to randomly lie\n\u003e about their `max_htlc` to still be noticed by nodes who try to filter out\n\u003e nodes who do not update their `max_htlc`s.\n\u003e (maximal lying is to always say 50% of your capacity is in `max_htlc`,\n\u003e your node can lie by setting `max_htlc` from 35%-\u003e65%, you can coordinate\n\u003e this with another lying peer node too by use of an odd message number to\n\u003e set up the lying protocol so both of you can lie about the channel capacity\n\u003e consistently)\n\u003e\n\u003e I think your best bet is really to utilize feerates, as lying with those\n\u003e is expected to lead to economic loss.\n\u003e\n\u003e \u003csnip\u003e\n\u003e\n\u003e \u003e # Node Fee Optimization \u0026 Fee Rate Cards\n\u003e \u003e\n\u003e \u003e Over the past few years, a common thread we've seen across successful\n\u003e \u003e routing nodes is dynamic fee setting as a way to encourage/discourage\n\u003e \u003e traffic. A routing nodes can utilize the set of fees of a channel to\n\u003e either\n\u003e \u003e make it too expensive for other nodes to route through (it's already\n\u003e \u003e depleted don't try unless you'll give be 10 mil sats, which no one\n\u003e would) or\n\u003e \u003e very cheap, which'll incentivize flows in the other direction. If all\n\u003e nodes\n\u003e \u003e are constantly sending out updates of this nature, then it can generate a\n\u003e \u003e lot of traffic, and also sort of leak more balance information overtime\n\u003e \u003e (which some nodes are already doing: using fees/max_htlc to communicate\n\u003e \u003e available balances).\n\u003e \u003e\n\u003e \u003e One attendee proposed allowing nodes to express a sort of fee gradient\n\u003e via a\n\u003e \u003e static curve/bucket/function, instead of dynamically communicating what\n\u003e the\n\u003e \u003e latest state of the fee+liquidity distribution looks like. A possible\n\u003e \u003e manifestation could be a series of buckets, each of which with varying\n\u003e fee\n\u003e \u003e rates. If your payment consumes 50% of channel balance, then you pay this\n\u003e \u003e rate, otherwise if it's 5% you pay this rate, etc, etc.\n\u003e\n\u003e I think this is not what was actually proposed?\n\u003e\n\u003e As I understood it, the percent range is not how much the payment consumes\n\u003e of the channel balance but instead the percent range is the\n\u003e probability-of-success given a uniform distribution of channel balance.\n\u003e\n\u003e For instance if the current channel balance is currently 67%, then the\n\u003e forwarding node will succeed all payments that pay a fee from the 33% fee\n\u003e card or higher, otherwise fail the payment with \"not enough fees\".\n\u003e\n\u003e The intent is that payers will treat 100% - fee_card_percent as the\n\u003e probability-of-failure of that channel, and can select which fee card\n\u003e maximizes both its probability-of-failure and max-fee in some kind of\n\u003e reasonable exchange rate.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220615/56c7bcf8/attachment-0001.html\u003e",
"sig": "5e97b831c3106c5ae12c22f00b7b89831a06c1b0d377456414ebbc1ffe233b5e47ff54c04348f62c140cab0c2a638448c7755aa4671c11362d4dc6195734653e"
}