João Valente [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-01 📝 Original message: Hello ZmnSCPxj! You are ...

📅 Original date posted:2020-12-01
📝 Original message:
Hello ZmnSCPxj!

You are completely right in saying that LDR presents a bigger barrier in
the sense that It needs to be running on literally every node in a payment
path for it to work whereas 'feeadjuster' can help the sender even if only
one node in the payment path is running it. That is definitely a big LDR
disadvantage.
About the specs... My approach was thinking about LDR as an independent
protocol with an independent protocol specification which would be
implemented by software that run alongside a spec-compliant lightning node,
which is why I was saying that there is no need for a lightning-spec change.
I started trying to define this new specification it on an extended version
of the paper, it's available here:
https://drive.google.com/file/d/1tSd5jKny_jLL6M1OuRkIc3NLaNFMBdJ_/view?usp=sharing
Also started (early beginnings!) to write the LDR-spec compliant software,
targeting lnd and bitcoind: https://github.com/jsmvalente/ldRouting

Kind regards,
João Valente

On Tue, 1 Dec 2020 at 16:34, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Joao,
>
> > Hello ZmnSCPxj,
> >
> > Thank you for taking the time to read the paper and sending over some
> feedback, can't stress enough how important that is.
> > I took a look at the `feeadjuster` plugin for C-Lightning and although
> it goes in the same direction as LDR in the sense that it allows for better
> routes by signalling channel balance availability. It does it through a
> dynamic fee adjustment though, where LDR is more explicit and goes one step
> further, directly sharing channel balance information. I'm not sure how
> these two solutions would compare in practice though but I imagine that
> sharing more information would give LDR a performance edge.
> > Oh, and there's no need for a spec change. It could work as a separated
> LN overlay network.
>
> I believe it would --- either you write the code for this overlay network
> for all extant node software (though I suppose targeting lnd will get you
> 90% of the network anyway...), or you standardize so all implementations
> are going to target implementing the overlay network.
>
> On the other hand, using fees as the signaling just reuses an existing
> signaling layer, and affects payers in the expected ways --- all existing
> implementations already try to minimize fees, so signaling a low fee when
> you have high capacity on a channel already does the "right thing" on the
> network today.
>
> In short, by using fees as a signaling layer you can get something like
> this partly working for most payers today even if only a small number of
> nodes run `feeadjuster` or CLBOSS, whereas with LDR you need most payers to
> upgrade to using the new overlay network in order to get similar benefit, I
> think, in which case you should really push to standardize it in the specs.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/9806b83b/attachment.html>;