Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-09 📝 Original message: Hi Clara, Thanks for ...
📅 Original date posted:2022-12-09
📝 Original message:
Hi Clara,
Thanks for rolling the ball forward.
On the agenda, a few more thoughts.
> 1. Which parameters should be considered in reputation-based solutions?
I think before thinking about the parameters of reputation-based solutions,
we should discuss the security goal we're aiming to achieve with any
potential jamming solutions. Browsing the solution space some have aimed to
increase the opportunity cost for the attacker (e.g liquidity slots), some
to reduce the jamming intensity (e.g circuit breakers), some inflicting a
on-chain fee damage cost back to the adversary (e.g stake certificates),
some to achieve economic hedge of the routing hops (e.g unconditional
fees, reputation credentials). As of today, I would say a security goal
designed in the term of a monetary strategy could be more acceptable to the
routing hops node operators. Beyond that, I believe there is capturing this
design goal in a "measurable" notion, such as the unjamming lightning
paper's breakeven point, and see how we can enrich this "measurable" notion.
> 2. Circuitbreaker [1]
While reviewing the circuitbreaker last week, I started to wonder if there
wasn't another "hidden" issue while solving channel jamming, namely
congestion control of the HTLC flows. A node operator is not only
interested that any liquidity unit allocated for a HTLC forward is paid
back with routing fees, but also in case of more forward demand than
liquidity offer, ready to process it (potentially by deferring and sending
backpressure messages to the HTLC sender). I don't know, though I think
that can be an interesting point to discuss.
> 3. Onion relay network [2] and its potential uses.
Onion relay network rate-limits have been discussed earlier this year, with
a probabilistic backpressure scheme proposed. If the onion relay traffic
starts to have economically-weighable traffic (offers, credentials tokens,
etc), there could be a risk of onion-jamming. For the bootstrap of the
onion relay network, I believe this could be solved by leveraging more the
channel-network topology for the design of a solution. We could re-use the
evaluation framework from the unjamming lightning paper, I guess.
In the meeting, I think it could be very valuable if we have reliable
transcripts and if we start to maintain a community repository, where we
can pin the issues, problems and ideas.
On the frequency of the meeting, note some Lightning developers raised the
concern that biweekly might be too much:
https://gnusha.org/lightning-dev/2022-11-23.log (once a month could work
well too, if we have a sound agenda).
Best,
Antoine
Le jeu. 8 déc. 2022 à 11:08, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi all,
>
> The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the
> following:
>
> 1. Which parameters should be considered in reputation-based solutions?
> 2. Circuitbreaker [1]
> 3. Onion relay network [2] and its potential uses.
>
> The link to the call: https://meet.jit.si/UnjammingLN
>
> See you there,
> Clara
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html
>
> On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman <
> clara.shikhelman at gmail.com> wrote:
>
>> Hi all,
>>
>> In light of recent conversations ([1],[2]), the agenda for the call
>> tomorrow (Monday the 28th, 7 pm UTC) is roughly the following:
>>
>> 1. Overview of solutions under discussion
>> 2. Reputation (local/tokens)
>> 3. Fees
>>
>> This is the link to the call: https://meet.jit.si/UnjammingLN
>>
>> See you there,
>> Clara
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20221208/e56d9ec4/attachment.html>;
📝 Original message:
Hi Clara,
Thanks for rolling the ball forward.
On the agenda, a few more thoughts.
> 1. Which parameters should be considered in reputation-based solutions?
I think before thinking about the parameters of reputation-based solutions,
we should discuss the security goal we're aiming to achieve with any
potential jamming solutions. Browsing the solution space some have aimed to
increase the opportunity cost for the attacker (e.g liquidity slots), some
to reduce the jamming intensity (e.g circuit breakers), some inflicting a
on-chain fee damage cost back to the adversary (e.g stake certificates),
some to achieve economic hedge of the routing hops (e.g unconditional
fees, reputation credentials). As of today, I would say a security goal
designed in the term of a monetary strategy could be more acceptable to the
routing hops node operators. Beyond that, I believe there is capturing this
design goal in a "measurable" notion, such as the unjamming lightning
paper's breakeven point, and see how we can enrich this "measurable" notion.
> 2. Circuitbreaker [1]
While reviewing the circuitbreaker last week, I started to wonder if there
wasn't another "hidden" issue while solving channel jamming, namely
congestion control of the HTLC flows. A node operator is not only
interested that any liquidity unit allocated for a HTLC forward is paid
back with routing fees, but also in case of more forward demand than
liquidity offer, ready to process it (potentially by deferring and sending
backpressure messages to the HTLC sender). I don't know, though I think
that can be an interesting point to discuss.
> 3. Onion relay network [2] and its potential uses.
Onion relay network rate-limits have been discussed earlier this year, with
a probabilistic backpressure scheme proposed. If the onion relay traffic
starts to have economically-weighable traffic (offers, credentials tokens,
etc), there could be a risk of onion-jamming. For the bootstrap of the
onion relay network, I believe this could be solved by leveraging more the
channel-network topology for the design of a solution. We could re-use the
evaluation framework from the unjamming lightning paper, I guess.
In the meeting, I think it could be very valuable if we have reliable
transcripts and if we start to maintain a community repository, where we
can pin the issues, problems and ideas.
On the frequency of the meeting, note some Lightning developers raised the
concern that biweekly might be too much:
https://gnusha.org/lightning-dev/2022-11-23.log (once a month could work
well too, if we have a sound agenda).
Best,
Antoine
Le jeu. 8 déc. 2022 à 11:08, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> Hi all,
>
> The agenda for next week's meeting (Monday the 12th, 7 pm UTC) is the
> following:
>
> 1. Which parameters should be considered in reputation-based solutions?
> 2. Circuitbreaker [1]
> 3. Onion relay network [2] and its potential uses.
>
> The link to the call: https://meet.jit.si/UnjammingLN
>
> See you there,
> Clara
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003780.html
>
> On Sun, Nov 27, 2022 at 9:48 PM Clara Shikhelman <
> clara.shikhelman at gmail.com> wrote:
>
>> Hi all,
>>
>> In light of recent conversations ([1],[2]), the agenda for the call
>> tomorrow (Monday the 28th, 7 pm UTC) is roughly the following:
>>
>> 1. Overview of solutions under discussion
>> 2. Reputation (local/tokens)
>> 3. Fees
>>
>> This is the link to the call: https://meet.jit.si/UnjammingLN
>>
>> See you there,
>> Clara
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>> [2]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20221208/e56d9ec4/attachment.html>;