Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-27 📝 Original message: Right, but there are ...
📅 Original date posted:2020-01-27
📝 Original message:
Right, but there are approaches that are not as susceptible - an
obvious, albeit somewhat naive, approach would be to define a fixed and
proportional max fee, and pick a random (with some privacy properties eg
biasing towards old or good-reputation nodes, routing across nodes
hosted on different ISPs/Tor/across continents, etc) route that pays no
more than those fees unless no such route is available. You could
imagine hard-coding such fees to "fees that are generally available on
the network as observed in the real world".
Matt
On 1/27/20 3:55 PM, ZmnSCPxj wrote:
> Good morning Matt,
>
> Thread-hijack...
>
>> route-hijacks (aka someone providing routing for a lower fee
>> and users happily taking it)
>
> I observe that this is something of a catch-22.
>
> If users *notice* lower fees and go to lower-fee channels, then route-hijacking is possible and surveillors can pay (via sacrificed fees) for better surveillance.
> If users *ignore* lower fees, then forwarding nodes will jack up their prices to 21 million Bitcoin `fee_base`, because users are going to go through their nodes with equal probability as lower-priced nodes.
>
> In many ways, traits that make one a good forwarding node (large number of channels, cheap fees, central location, high uptime, low latency...) also makes one a good surveillance node, sigh.
> Fortunately this second-layer Lightning network remains censorship-resistant (censorship leads to loss of profit from fees, same as on the blockchain layer, and censors can be evicted by jacking up your willingness to pay fees (including onchain fees to move your channels away from the censoring node and towards the node you want to pay to, which again is an eviction of the censor), just as effectively as on the blockchain layer).
>
> Regards,
> ZmnSCPxj
>
>> 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:
Right, but there are approaches that are not as susceptible - an
obvious, albeit somewhat naive, approach would be to define a fixed and
proportional max fee, and pick a random (with some privacy properties eg
biasing towards old or good-reputation nodes, routing across nodes
hosted on different ISPs/Tor/across continents, etc) route that pays no
more than those fees unless no such route is available. You could
imagine hard-coding such fees to "fees that are generally available on
the network as observed in the real world".
Matt
On 1/27/20 3:55 PM, ZmnSCPxj wrote:
> Good morning Matt,
>
> Thread-hijack...
>
>> route-hijacks (aka someone providing routing for a lower fee
>> and users happily taking it)
>
> I observe that this is something of a catch-22.
>
> If users *notice* lower fees and go to lower-fee channels, then route-hijacking is possible and surveillors can pay (via sacrificed fees) for better surveillance.
> If users *ignore* lower fees, then forwarding nodes will jack up their prices to 21 million Bitcoin `fee_base`, because users are going to go through their nodes with equal probability as lower-priced nodes.
>
> In many ways, traits that make one a good forwarding node (large number of channels, cheap fees, central location, high uptime, low latency...) also makes one a good surveillance node, sigh.
> Fortunately this second-layer Lightning network remains censorship-resistant (censorship leads to loss of profit from fees, same as on the blockchain layer, and censors can be evicted by jacking up your willingness to pay fees (including onchain fees to move your channels away from the censoring node and towards the node you want to pay to, which again is an eviction of the censor), just as effectively as on the blockchain layer).
>
> Regards,
> ZmnSCPxj
>
>> 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
>
>