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
