Note the distinction - there is almost nothing done today to prevent spam and route-hijacks (aka someone providing routing for a lower fee and users happily taking it) 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
