On Tue, Apr 18, 2023 at 07:17:34PM +0000, jlspc wrote:
> > 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".
> Yes, I found it very difficult to think about, and I kept getting confused
> between concepts like "user", "node", "channel", and "factory".
> The thing that works best for me is to create a clear definition of each of
> these terms, along with the term "party".
Okay, that makes sense. I think it might work better to treat "node" as
synonymous with "user" rather than "party" though -- that way you can say
"you create a lightning node by running lightning node software such as
lnd/cln/eclair/etc". That means not all vertices in the payment routing
network are nodes; but all vertices in the *gossip* network are nodes,
so that seems okay.
Just saying "channel" (instead of "logical channel") and "utxo/off-chain
utxo" (instead of "physical channel") might also work okay.
> I also think it's best to imagine a world in which there are hierarchical
> channels, but there are no "factories" per se.
Personally, I use "channel factory" to mean "anything that lets a
single utxo contain multiple channels between different users, that
can be reorganised without going on-chain", so I think once you've got
hierarchial channels, you've implicitly got (a variation of) channel
factories.
(I'm not sure "channel factories" is really the most evocative way of
describing them -- at least when I think of a factory, I think the product
should be accessible to everyone; but for channel factories you have to
be involved in the factory's original mutlisig to be able to use one of
its channels. Maybe better to call them "channel coops", where you're
creating a little commune of friends/allies to work together with each
other. Could be pronounced like "workers' co-op" or like "chicken coop",
either way :)
> * Logical Channel: a layer 2 construct that consists of all of the physical
> channels owned by a specific pair of parties
> - the size (capacity) of a logical channel is the sum of the sizes of their
> physical channels
> - (Footnote: It's possible, with a significant amount of software
> development work that I in no way discount, to route a payment through a
> logical channel where the payment traverses multiple physical channels at the
> same time. This is done by using separate HTLCs, all sharing the same secret,
> in each of the physical channels that the payment traverses. I can write more
> about this if that would be helpful.)
I think it might already be interesting to write a BOLT/BLIP for that?
Having a single channel backed by multiple on-chain utxos is probably
interesting for splicing (adding or spending a utxo while keeping the
channel open on the other utxos might be able to be done more simply than
splicing in general), and having multiple utxos might let you increase
some of your channel limits, eg `max_accepted_htlcs` might be able to
be increased to 483*U where U is the number of UTXOs backing the channel.
> > 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.
> Regarding the specific issues you raised:
> Q: How do you link "FG" back with "F" and "G"?
> A: In terms of gossiping and the channel graph, you don't
Yeah, I think that simplifies things substantially.
I think the main thing that misled me here was the "CD->E->FG" payment
chain -- it doesn't make sense to me why E would want to devote funds
that can only be used for rebalancing channels, but not normal payments.
Having that be CD->DE->FG seems like it would make much more sense in that
model. (Though, obviously, no one except D and E could necessarily tell
the difference between those two scenarios in practice, and just because
something doesn't make sense, doesn't mean nobody will actually do it)
The other thing was that going from N nodes to C*N channels, then
re-considering each of the C*N channels (A->B, etc) as also potentially
being nodes and adding an additional K*C*N channels (AB->CD, etc) seemed
like it might be quadratic to me. But it's probably not -- C (channels per
node) and K (utxos per channel) are probably constant or logarithmic in
N, so it's probably okay?
On the other hand, I could see the rebalancing channels not actually
being very useful for routing payments (they require 3+ signatures,
and may not even be publicly connected to any of the level-1 nodes),
so it could make sense to just treat them as two different networks,
where regular people doing payments only see the base channels, but
high-availability nodes also find out about the rebalancing channels.
If so, then the extra nodes/channels in the rebalancing graph only affect
people who can afford to dedicate the resources to storing it anyway,
so it's probably fine.
> Q: How do you decide fees?
> Q: How do you communicate fees/max_htlc/etc.?
Yep, both these bcome trivial.
> > 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.
I was assuming a payment path using the channels (X->A) and (AB->C)
here. But that's not something anyone can pick in this model, unless A
announces an (A->AB) path that others can use to link them, and in that
case either {A,AB} is a real channel and everything works fine, or it's
a fake one that A and B have negotiated because they're both happy if
the AB channel changes capacity randomly.
> Finally, I realize that creating a world without factories doesn't sound like
> a good solution for scaling Bitcoin. However, I believe hierarchical channels
> largely solve the problem of resizing channels off-chain.
I think this is probably a lot harder in practice than in theory? If
you have an {A,B} channel holding 3 BTC across two hierarchial channels,
{X:1 BTC, AB:1 BTC} and {Y:1 BTC, AB:2 BTC}, and someone wants to route
0.5 BTC through X->AB->Y, then that will look something like:
{X:1, AB:1} {AB:2, Y:1}
{X:0.5, XAB:0.5, AB:1} {AB:2, Y:1}
{X:0.5, XAB:0.5, AB:1} {AB:1.5, ABY:0.5 Y:1}
and either:
{X:1, AB:1} {AB:2, Y:1} (on failure)
or
{X:0.5, AB:1.5} {AB:1.5, Y:1.5} (on success)
But what if you're in the middle of routing 2 BTC over the A,B channel
in the meantime? In that case you need some of the AB payments to be
conditional on the success path of XAB and the failure path of ABY.
I *think* that's fine, and doesn't involve a combinatorical blowup in
the event that you're routing rebalances across multiple off-chain utxos
-- you just end up splitting your channel across {X+2*Y} utxos where X
is the number of "physical" channels and "Y" is the number of pending
rebalances. But it seems like there's a fair chunk of complexity and
maybe some extra round trips (eg, moving a pending HTLC from being
purely in the AB:2 output to being split across the {XAB:0.5/success and
ABY:0.5/timeout} atomically seems tricky?).
(I figure implementing something eltoo-like via 2-user tunable penalty
channels and/or ln-symmetry (let alone splicing, taproot funding
addresses, and ptlcs) is a sufficient sink for all the available
engineering effort any time soon, but talking about hierarchial/factory
things well in advance of when they could reasonably be implemented is
fun too)
Cheers,
aj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
