[EthanHeilman]

>1. You need to have a computer constantly online or your counter party can easily steal all your money. This leaves you vulnerable to all sorts of attacks.

This isn't not the case. You can outsource channel monitoring to other peers in the network such that if anyone attempts to cheat you, they can punish the cheater and claim a reward. Bitcoin makes various security assumptions such as 51% of the mining power is honest, users have access to perfect information about the blockchain, etc... The LN, if the software is designed correctly, is likely to more realistic security assumptions than Bitcoin itself.

>3. It's relatively expensive to create and destroy channels at about two transactions per channel. Lightning proponents claim that this will be rare, but that can only be the case if there is minimal net flow of money. This is trivially not the case because users will be sending bitcoin more than they recieve and the reverse for retailers.

Channel factories[0] address this problem such that you can move channels between participants without touching the blockchain. There are also ways to do this whereby you switch n channels for a single transaction that spends log n outputs.

[0]: Scalable Funding of Bitcoin Micropayment Channel Networks https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7c...

[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.