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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
