From jvalente96 at gmail.com Tue Dec 1 17:20:59 2020 From: jvalente96 at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Valente?=) Date: Tue, 1 Dec 2020 17:20:59 +0000 Subject: [Lightning-dev] Lightning Distributed Routing In-Reply-To: References: <3G48KsBdy8f5ovk3zNofxVhijOloLuyS4-ywi-gAEX1ZkAWZDuXEcxJ5YkV0ANlhKGU2kqg_FO_PrjM-5xsOuNK6Klw_pKFFcY6Pci8hVqo=@protonmail.com> Message-ID: 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 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: