Chains of unconfirmed transactions only needed for channel opening.
The second lightning level, is OP_CSV or OP_MATURITY or whatever is the coolest name. It's relative to when the input got into a block, so it's like relative checklocktimeverify. This is a cool opcode. It lets you say you can spend this, but only once it's a week old, or you know a thousand blocks old. This allows a lot of cool things for lightning channels. The channel open and close transactions are about the same size. The channel duration is indefinite and you can keep it open for as long as you want. Both channels can cooperatively close it "immediately". There is a timeout period for the uncooperative close time, which you can make perhaps 1 week like in the other, if the counterparty disappears and he's gone, you can push the current channel state to the blockchain and then I have to wait a week to collect the money back to a non-lightning P2SH output. You could tweak this from 1 week to 1 day or 1 month or something. You have to watch the blockchain at least once during that period. You have to check the phone or blockchain at least once a week or something. That channel duration matters for the timeout of the checksequenceverify matters for channel monitoring which must still be done by the user.
Frankly, I don't understand, how channels of indefinite duration could be created without SegWit or SIGHASH_NOINPUT or another possible patch, which makes txid independent on signatures. Explanation appreciated.