Olaoluwa Osuntokun writes:
>> Rene Pickhardt brought up the issue of latency with regards to
>> nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin
>> StackExchange
>
> Not explicitly, but that strikes me as more of an implementation level
> concern. As an example, today more nodes
Matt Corallo writes:
> On 6/28/22 9:05 AM, Christian Decker wrote:
>> It is worth mentioning here that the LN protocol is generally not very
>> latency sensitive, and from my experience can easily handle very slow
>> signers (3-5 seconds delay) without causing too ma
Thanks Bastien for writing up the proposal, it is simple but effective I
think.
>> One issue I see w/ the first category is that a single party can flood the
>> network and cause nodes to trigger their rate limits, which then affects
>> the
>> usability of the onion messages for all other
Hi Matt,
Hi Joost,
let me chime in here, since we seem to be slowly reinventing all the
research on reputation systems that is already out there. First of all
let me say that I am personally not a fan of reputation systems in
general, just to get my own biases out of the way, now on to the why
Hi Antoine,
this is an intrinsic issue with reputation systems, and the main
reason I'm sceptical w.r.t. their usefulness in lightning.
Fundamentally any reputation system bases their expectations for the
future on experiences they made in the past, and they are thus always
susceptible to sudden
> > I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an
101 - 106 of 106 matches
Mail list logo
