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
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 spe
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 limi
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 "in
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 spli
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
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 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 an
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
> > > >
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
> > > * 76%->100%:
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...
> > .--~~--.
> > / \
> > / \
> > / \
> > / \
> > / \
> > --' `-
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 [0]
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...
> .--~~--.
> /\
>
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 f
14 matches
Mail list logo