Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-12 🗒️ Summary of this message: The paper ...
📅 Original date posted:2023-04-12
🗒️ Summary of this message: The paper discusses routing to a "channel" rather than a node, which poses complications for linking channels and deciding fees.
📝 Original message:
On Sat, Apr 08, 2023 at 10:26:45PM +0000, jlspc via Lightning-dev wrote:
> From my perspective, this paper makes two contributions (which, to be fair, may only be "interesting" :)
One thing that confuses me about the paper is how to think about routing
to a "channel" rather than a node -- ie the payment from "E->FG->A" where
"FG" isn't "F" or "G", but "both of them". It feels like there's a whole
mass of complications hidden in there from a routing perspective; like how
do you link "FG" back with "F" and "G", how do you decide fees, how do
you communicate fees/max_htlc/etc. I think it also implies that channel
capacity is no longer really something you can gossip very sensibly --
if you have a factory ((A,B),C,D,E) then every payment through AB to C
or D or E will decrease AB's channel capacity. You could still gossip the
capacity of the overall factory, and sum that to get an overall lightning
network capacity, of course. But a lot of the ways of simplifying it
also make it harder to do all the nice rebalancing.
Anyway, I've tried a few times now to put some thoughts together on that
and come up with nothing that I'm happy with, so figured it might be at
least worth posing explicitly as a problem...
Cheers,
aj
🗒️ Summary of this message: The paper discusses routing to a "channel" rather than a node, which poses complications for linking channels and deciding fees.
📝 Original message:
On Sat, Apr 08, 2023 at 10:26:45PM +0000, jlspc via Lightning-dev wrote:
> From my perspective, this paper makes two contributions (which, to be fair, may only be "interesting" :)
One thing that confuses me about the paper is how to think about routing
to a "channel" rather than a node -- ie the payment from "E->FG->A" where
"FG" isn't "F" or "G", but "both of them". It feels like there's a whole
mass of complications hidden in there from a routing perspective; like how
do you link "FG" back with "F" and "G", how do you decide fees, how do
you communicate fees/max_htlc/etc. I think it also implies that channel
capacity is no longer really something you can gossip very sensibly --
if you have a factory ((A,B),C,D,E) then every payment through AB to C
or D or E will decrease AB's channel capacity. You could still gossip the
capacity of the overall factory, and sum that to get an overall lightning
network capacity, of course. But a lot of the ways of simplifying it
also make it harder to do all the nice rebalancing.
Anyway, I've tried a few times now to put some thoughts together on that
and come up with nothing that I'm happy with, so figured it might be at
least worth posing explicitly as a problem...
Cheers,
aj