Lightning is a joke, with insoluble routing problems, a need for always-on nodes, the requirement to lock funds in channels, and the requirement for on-chain transactions to start and close channels. The BTC network can't process enough transactions to make even that viable.

>with insoluble routing problems

can you elaborate on this?

>a need for always-on nodes

AFAIK if you're not a payment hub (ie. you want to route other people's payments) you don't need to be always online.

> can you elaborate on this?

Haviong trouble finding it now, but google "lightning network routing problems" and you'll get a lot of results. IIRC the fundamental issue boils down to a hard mathematical problem about node traversal that is not yet solved. I am having trouble recalling the name right now, apologies.

> AFAIK if you're not a payment hub (ie. you want to route other people's payments) you don't need to be always online.

There have been ways that a counterparty can close a channel in their favour if you aren't online. Perhaps this has been fixed by now.

>There have been ways that a counterparty can close a channel in their favour if you aren't online. Perhaps this has been fixed by now.

AFAIK the fix is to have a service (or multiple) stay online for you, and I believe it could be done without requiring access to your private keys. If your counterparty broadcasts a stale transaction that's in their favor, your service will broadcast a newer transaction that reverts it.

I was hoping that link would explain how to actually make a transaction with the lightning network. Can you do that with the Bitcoin-Qt client?