Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-27 📝 Original message: Note the distinction - ...
📅 Original date posted:2020-01-27
📝 Original message:
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-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
>>>>
>
>
📝 Original message:
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-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
>>>>
>
>