Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-27 📝 Original message: Why require a funding ...
📅 Original date posted:2020-01-27
📝 Original message:
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 <lf-lists at mattcorallo.com
> <mailto:lf-lists at 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-bounces at lists.linuxfoundation.org
> <mailto:lightning-dev-bounces at lists.linuxfoundation.org>>
> > *On Behalf Of *Subhra Mazumdar
> > *Sent:* Monday, January 27, 2020 12:45 PM
> > *To:* lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at 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 at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
📝 Original message:
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 <lf-lists at mattcorallo.com
> <mailto:lf-lists at 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-bounces at lists.linuxfoundation.org
> <mailto:lightning-dev-bounces at lists.linuxfoundation.org>>
> > *On Behalf Of *Subhra Mazumdar
> > *Sent:* Monday, January 27, 2020 12:45 PM
> > *To:* lightning-dev at lists.linuxfoundation.org
> <mailto:lightning-dev at 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 at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>