Right, but there are approaches that are not as susceptible - an obvious, albeit somewhat naive, approach would be to define a fixed and proportional max fee, and pick a random (with some privacy properties eg biasing towards old or good-reputation nodes, routing across nodes hosted on different ISPs/Tor/across continents, etc) route that pays no more than those fees unless no such route is available. You could imagine hard-coding such fees to "fees that are generally available on the network as observed in the real world".
Matt On 1/27/20 3:55 PM, ZmnSCPxj wrote: > Good morning Matt, > > Thread-hijack... > >> route-hijacks (aka someone providing routing for a lower fee >> and users happily taking it) > > I observe that this is something of a catch-22. > > If users *notice* lower fees and go to lower-fee channels, then > route-hijacking is possible and surveillors can pay (via sacrificed fees) for > better surveillance. > If users *ignore* lower fees, then forwarding nodes will jack up their prices > to 21 million Bitcoin `fee_base`, because users are going to go through their > nodes with equal probability as lower-priced nodes. > > In many ways, traits that make one a good forwarding node (large number of > channels, cheap fees, central location, high uptime, low latency...) also > makes one a good surveillance node, sigh. > Fortunately this second-layer Lightning network remains censorship-resistant > (censorship leads to loss of profit from fees, same as on the blockchain > layer, and censors can be evicted by jacking up your willingness to pay fees > (including onchain fees to move your channels away from the censoring node > and towards the node you want to pay to, which again is an eviction of the > censor), just as effectively as on the blockchain layer). > > Regards, > ZmnSCPxj > >> in the routing DB today. The issue of >> anti-DoS is somewhat different - we do have reasonable protection from >> someone OOM'ing every node on the network by opening a billion channels. >> Anti-DoS could reasonably be accomplished with simple equivalent proofs, >> though of course they would be somewhat more expensive to create/validate. >> >> Matt >> >> On 1/27/20 3:19 PM, ZmnSCPxj wrote: >> >>> Good morning Subhra, >>> >>>> So introducing proof of knowledge of fund locked instead of revealing the >>>> amount of fund locked by counterparties will introduce added complexity >>>> while routing but how effective is this going to be against handling >>>> attacks like hijacking of routes and channel exhaustion ? >>> >>> The added complexity is spam-prevention, as mentioned, and not routing in >>> particular. >>> Pathfinding algorithms can just use the lower limit of the rangeproof to >>> filter out channels too small to pass a particular payment through, >>> C-Lightning (and probably other implementations) already does this, using >>> the known channel capacity as the limit (knowledge of the exact channel >>> capacity is a rangeproof whose lower limit equals the upper limit, yes?). >>> Now, since the proofs involved are likely to be larger than just a simple >>> 64-bit integer that indicates the location of the funding transaction on >>> the blockchain (24-bit blockheight, 24-bit transaction index within block, >>> 16-bit output index), the spam-prevention might end up requiring more data >>> than the spam it stops, so --- >>> (Though if Matt has some ideas here I would be greatly interested --- we do >>> have to change the encodings of short-channel-ids at some point, if only to >>> support channel factories....) >>> Regards, >>> ZmnSCPxj >>> >>>> On Mon, Jan 27, 2020, 20:12 Matt Corallo lf-li...@mattcorallo.com wrote: >>>> >>>>> Note that there's no real reason lightning nodes have to have >>>>> confidence in that - if a node routes your payment to the next hop, how >>>>> they do it doesn't really matter. Allowing things like non-lightning >>>>> "channels" (eg just a contractual agreement to settle up later between >>>>> two mutually-trusting parties) would actually be quite compelling. >>>>> The reason lightning nodes today require proof-of-funds-locked is >>>>> largely for DoS resistance, effectively rate-limiting flooding the >>>>> global routing table with garbage, but such rate-limiting could be >>>>> accomplished (albeit with a ton more complexity) via other means. >>>>> Matt >>>>> On 1/27/20 7:50 AM, Ugam Kamat wrote: >>>>> >>>>>> Hey Subhra – In order to have faith that the channel announced by the >>>>>> nodes is actually locked on the Bitcoin mainchain we need to have the >>>>>> outpoint (`txid` and `vout`) of the funding transaction. If we do not >>>>>> verify that the funding transaction has been confirmed, nodes can cheat >>>>>> us that a particular transaction is confirmed when it is not the case. >>>>>> As a result we require that nodes announce this information along with >>>>>> the public keys and the signatures of the public keys that was used to >>>>>> lock the funding transaction. >>>>>> >>>>>> This information is broadcasted in the `channel_announcement` message in >>>>>> the `short_channel_id` field which includes the block number, >>>>>> transaction number and vout. Since Bitcoin does not allow confidential >>>>>> transactions, we can query the blockchain and find out the channel >>>>>> capacity even when the amounts are never explicitly mentioned. >>>>>> >>>>>> Ugam >>>>>> >>>>>> From: Lightning-dev lightning-dev-boun...@lists.linuxfoundation.org >>>>>> *On Behalf Of *Subhra Mazumdar >>>>>> Sent: Monday, January 27, 2020 12:45 PM >>>>>> To: lightning-dev@lists.linuxfoundation.org >>>>>> Subject: [Lightning-dev] Not revealing the channel capacity during >>>>>> opening of channel in lightning network >>>>>> >>>>>> Dear All, >>>>>> What can be the potential problem if a channel is opened >>>>>> whereby the channel capacity is not revealed publicly but just a range >>>>>> proof of the attribute (capacity >0 and capacity < value) is provided ? >>>>>> Will it pose a problem during routing of transaction ? What are the pros >>>>>> and cons ? >>>>>> I think that revealing channel capacity make the channels susceptible to >>>>>> channel exhaustion attack or a particular node might be targeted for >>>>>> node isolation attack ? >>>>>> -- >>>>>> Yours sincerely, >>>>>> Subhra Mazumdar. >>>>>> >>>>>> Lightning-dev mailing list >>>>>> Lightning-dev@lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
