Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-27 📝 Original message: So introducing proof of ...
📅 Original date posted:2020-01-27
📝 Original message:
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> 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>
> > *On Behalf Of *Subhra Mazumdar
> > *Sent:* Monday, January 27, 2020 12:45 PM
> > *To:* 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
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/0d63c8b7/attachment.html>;
📝 Original message:
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> 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>
> > *On Behalf Of *Subhra Mazumdar
> > *Sent:* Monday, January 27, 2020 12:45 PM
> > *To:* 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
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/0d63c8b7/attachment.html>;