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