During the recent Oakland Dev Summit, some lightning engineers got
together to discuss DoS
protection for onion messages. Rusty proposed a very simple
rate-limiting scheme that
statistically propagates back to the correct sender, which we describe
in details below.
You can also read this in gist
On Sun, Jun 05, 2022 at 02:29:28PM +, ZmnSCPxj via Lightning-dev wrote:
Just sharing my thoughts on this.
> Introduction
>
> Optimize for reliability+
>uncertainty+fee+drain+uptime...
> .--~~--.
> /\
>
Thanks for this Alex.
Here's a transcript of your recent presentation at Bitcoin++ on Minisketch and
Lightning gossip:
https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/
Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core
Good morning aj,
> On Sun, Jun 05, 2022 at 02:29:28PM +, ZmnSCPxj via Lightning-dev wrote:
>
> Just sharing my thoughts on this.
>
> > Introduction
> >
> > Optimize for reliability+
> > uncertainty+fee+drain+uptime...
> > .--~~--.
> > / \
> > / \
> > / \
> > / \
> > / \
> > --'
Hi Michael,
Thanks for the transcript and the questions, especially those you asked in
Gleb's original Erlay presentation.
I tried to cover a lot of ground in only 30 minutes and the finer points may
have suffered. The most significant difference in concern between bitcoin
transaction relay
On Wed, Jun 29, 2022 at 12:38:17PM +, ZmnSCPxj wrote:
> > > ### Inverting The Filter: Feerate Cards
> > > Basically, a feerate card is a mapping between a probability-of-success
> > > range and a feerate.
> > > * 00%->25%: -10ppm
> > > * 26%->50%: 1ppm
> > > * 51%->75%: 5ppm
> > > *
Good morning aj,
> On Wed, Jun 29, 2022 at 12:38:17PM +, ZmnSCPxj wrote:
>
> > > > ### Inverting The Filter: Feerate Cards
> > > > Basically, a feerate card is a mapping between a probability-of-success
> > > > range and a feerate.
> > > > * 00%->25%: -10ppm
> > > > * 26%->50%: 1ppm
> > > >
Hi Rusty,
Thanks for the feedback!
> This is over-design: if you fail to get reliable gossip, your routing will
> suffer anyway. Nothing new here.
Idk, it's pretty simple: you're already watching for closes, so if a close
looks a certain way, it's a splice. When you see that, you can even take
Hi t-bast,
Happy to see this finally written up! With this, we have two classes of
proposals for rate limiting onion messaging:
1. Back propagation based rate limiting as described here.
2. Allowing nodes to express a per-message cost for their forwarding
services, which is described here
Adding a noticeable on-chain signal runs counter to the goal of the move
to taproot / gossip v2, which is to make lightning's onchain footprint
indistinguishable from
any other onchain usage.
I'm admittedly a bit confused as to why onchain signals are even being
seriously
proposed. Aside from
Thanks Bastien for writing this up! This is a pretty trivial and straightforward way to rate-limit
onion messages in a way that allows legitimate users to continue using the system in spite of some
bad actors trying (and failing, due to being rate-limited) to DoS the network.
I do think any
Had another thought: if you've seen a chain close but also have a gossip
message that
indicates this is a splice, you SHOULD propagate that gossip more
urgently/widely than
any other gossip you've got. Adding an urgency metric to gossip is fuzzy to
enforce... *handwaves*.
You *do* get the onchain
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
> Thanks for the feedback!
>
>> This is over-design: if you fail to get reliable gossip, your routing will
>> suffer anyway. Nothing new here.
>
> Idk, it's pretty simple: you're already watching for closes, so if a close
> looks a certain way, it's a
Heya Laolu,
From my PoV, adding prepayments to onion messages is putting the cart before
the horse a bit, think there's a good amount of recourse before resorting to
that.
Seems there are two cases to address here:
1. People are trying to stream GoT over lightning
In this case, just rate
14 matches
Mail list logo
