[Klathmon]

Don't channel factories only allow you to move channels between users who were a part of the original multiparty transaction?

It's a fantastic idea, but I feel it more has usecases between popular hubs and less for actual users.

Although they also have the side effect of making the initial transaction on the blockchain up to 90% cheaper, so they are useful there too!

[EthanHeilman]

>It's a fantastic idea, but I feel it more has usecases between popular hubs and less for actual users.

Won't actual users be connected to popular hubs? For instance Alice's connects to Hub1, Hub2, and Hub3 via a channel factory.

[Klathmon]

That is true! The biggest downside with channel factories is that noncompliance from one party forces the whole factory to close and reopen without them, which gets much more likely with every added participant. But if there is only one participant which is "untrustworthy" (on some level, in the sense that they aren't trusted to stay online as much as well known nodes are), then the system could work fine.

That's really interesting, and opens up a lot of ideas. Still, I think we should avoid trying to bring up channel factories for now. They are still a few steps away as they add more complexity to an already complex system. Focus on getting LN up and working, then add in nice-to-haves like channel factories slowly once vendors are on-board.

[EthanHeilman]

I agree there is enough to do with getting the LN up and running. However the future of layer two protocols is extremely bright and the current limitations of the system are clearly surmountable. Add op code support for channel factories and you can change key sets on an arbitrary number of factories with one 200 byte on-chain transaction.

Given all the money flying around ICOs, it is pretty amazing that there isn't more money flowing into layer two. Hopefully that will change in 2018-2019.