Loki Verloren [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-10-11 to 2022-12-09
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:07:41

- reply

📅 Original date posted:2022-12-09
📝 Original message:
Hi,
I am quite busy and focused on developing the Indranet lighting monetised onion relay network project, but I dropped my 2c in the hat relating to this, I just wanted to make a comment regarding related spam mitigation strategies which also form the basis of my project.
When nodes in the network will not process data in a message without being paid, the cost of spamming useless data rises dramatically. The asymmetries that can exist between generating data and processing it lead to vulnerabilities, not just DoS of network but attacking memory and processing capacity of nodes.
Might I suggest that if the idea of charging for services existed, and a scheme for accounting the consumption of pre-paid service were to exist, similar to the one I am devising for Indra, it would have the same benefit also for Lightning network in general: potential to earn a strongly guaranteed margin of profit, and that leading to the eventual growth of the network as it isn't a loss-leader investment. Wherever the economics favor attackers, making such services paid only or paid plus a dribble of free service, like the Bitcoin mempool, attackers will look elsewhere for easy prey.
I will be keeping an eye on how security protocols develop with LN and hope to be able cross-pollinate where things intersect. I do think that onion routing is a loss-leader unless it has anonymous payments in it, and anonymous payments themselves are a utility for LN.
- l0k1
> Subject: Re: [Lightning-dev] Jamming mitigation call
> Message-ID:
> CALZpt+GsNhZcv1u6_hjgt=1WpGE0nE5ygqHN3EUhjHTO9T=Y7w at mail.gmail.com
>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 8 Dec 2022 22:51:31 -0500
> From: Clara Shikhelman clara.shikhelman at gmail.com
>
> To: Antoine Riard antoine.riard at gmail.com
>
> Cc: lightning-dev lightning-dev at lists.linuxfoundation.org
>
> Subject: Re: [Lightning-dev] Jamming mitigation call
> Message-ID:
> CACtNmG6BQ_assXd5SyvZz7VGycystnVugM4JN=m06roySKe1LA at mail.gmail.com
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antoine,
>
> Thanks for your input.
>
> The first item is there because we agreed to start where we left off at the
> end of the last meeting.
>
> About your comments on the other items ? I think they are very interesting,
> but you should probably write them in the relevant thread. Let's keep this
> for meeting housekeeping.
>
> I agree about a repository, will do this soon.
>
> As for the frequency, the next one will be in a month because of the
> holidays. I like the biweekly because things stay fresh. Of course, there
> is no need for everyone to attend, we'll start publishing a summary for
> those who can't.
>
> If you would like to write a transcript, it would be very useful and much
> appreciated.
>
> Best,
> Clara
>
>
> On Thu, Dec 8, 2022 at 10:31 PM Antoine Riard antoine.riard at gmail.com
>
> wrote:
>
> > 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/52e3595c/attachment.html
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> ------------------------------
>
> End of Lightning-dev Digest, Vol 88, Issue 12
> *********************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x96FE6FEA.asc
Type: application/pgp-keys
Size: 1775 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221209/c8590258/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221209/c8590258/attachment-0001.sig>

2023-06-09 13:07:32

- reply

📅 Original date posted:2022-12-02
📝 Original message:
This subject makes a strong argument, along with the onion routed messaging part of Bolt 12 for an independent, Lightning funded onion routing relay network, over which all such kinds of traffic and security can be provided.
I'm working on such a project, which will be initially built to support LND/BTCD/Neutrino: https://github.com/Indra-Labs/indra One of its key innovations is a mechanism for path tracing, which enables the deduction of likely nodes that are currently not functioning correctly or malicious or offline or congested, via a process of deduction, while keeping the client originating traffic hidden from nodes in the path.
Channels running across this overlay network would not be possible to jam and with many nodes a lot of traffic would pass through opaque tunnels, which would make jamming harder. The payment scheme in it also might work as a full solution to the adding of a cost against attempts to jam channels. My current idea for reputation is just a simple measure of client success ranking nodes by how recent and reliable they are, creating a loose consensus on the network of which nodes are better connected and dependable. Because it will use a median/zip merging process for evaluating the nodes it is hard for an adversary to damage the reputation of good nodes without also having to run a lot of nodes and for those nodes to also develop a good reputation.
Anyway, just some thoughts on the subject, not sure how useful or correct they are at this point.
Sent with Proton Mail secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/398391a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x96FE6FEA.asc
Type: application/pgp-keys
Size: 1775 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/398391a6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/398391a6/attachment.sig>

2023-06-07 23:15:04

- reply

📅 Original date posted:2022-10-11
📝 Original message:The recent 998 of 999 multisig segwit transaction highlights a problem with BIP144. As the solution applied for btcd shows, effectively a single transaction witness can be the same as the maximum block size.
11000 bytes may not be so unreasonable but now there is a special case with a block over 33k worth of witness data.
A concrete limit should be set on the maximum size of a transaction witness, and this should be discussed in a more general sense about total transaction sizes.
In the absence of a specification, it becomes impossible to properly implement and the status quo devolves to the actual implementation in the bitcoin core repository code.
I think the weight calculation should escalate exponentially to discourage putting transactions like this on the chain. The price was equivalent to about $5 to do this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/05dcf239/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - loki at cybriq.systems - 0x7BC3C653.asc
Type: application/pgp-keys
Size: 653 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/05dcf239/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/05dcf239/attachment.sig>