Why require a funding locked? Just require proof-of-UTXO - its only for anti-DoS, again there is no reason to require a standard lightning channel on-chain for this.
In general proving 2-of-2 multisig UTXO ownership doesn't do much to prevent route hijacking to begin with, so it shouldn't be much different. Matt On 1/27/20 3:04 PM, Subhra Mazumdar wrote: > 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 ? > > On Mon, Jan 27, 2020, 20:12 Matt Corallo <[email protected] > <mailto:[email protected]>> 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 > <[email protected] > <mailto:[email protected]>> > > *On Behalf Of *Subhra Mazumdar > > *Sent:* Monday, January 27, 2020 12:45 PM > > *To:* [email protected] > <mailto:[email protected]> > > *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 > > [email protected] > <mailto:[email protected]> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
