On 5/26/22 8:59 PM, Alex Myers wrote:
Ah, this is an additional proposal on top, and requires a gossip "hard fork",
which means your new
protocol would only work for taproot channels, and any old/unupgraded channels
will have to be
propagated via the old mechanism. I'd kinda prefer to be
> > The update contains a block number. Let's say we allow an update every
> > 100 blocks. This must be <= current block height (and presumably, newer
> > than height - 2016).
> >
> > If you send an update number 60, and then 600100, it will propagate.
> > 600099 will not.
>
>
> Ah, this is an
On 5/26/22 1:25 PM, Rusty Russell wrote:
Matt Corallo writes:
I agree there should be *some* rough consensus, but rate-limits are a
locally-enforced thing, not a
global one. There will always be races and updates you reject that your peers
dont, no matter the
rate-limit, and while I agree
Dear fellow lightning developers,
please note my recent blog article titled "Price of Anarchy from selfish
routing strategies on the Lightning Network" [1] where we investigate how
the selfish behavior of nodes sending Bitcoin over the Lightning Network
may lead to higher drain on channels which
Matt Corallo writes:
>>> I agree there should be *some* rough consensus, but rate-limits are a
>>> locally-enforced thing, not a
>>> global one. There will always be races and updates you reject that your
>>> peers dont, no matter the
>>> rate-limit, and while I agree we should have guidelines,
Oops, sorry, I don't really monitor the dev lists but once every few months so
this fell off my plate :/
On 4/28/22 6:11 PM, Rusty Russell wrote:
Matt Corallo writes:
OK, let's step back. Unlike Bitcoin, we can use a single sketch for
*all* peers. This is because we *can* encode enough
