I have read somewhere in the forum that the lock out time if in case there is an uncooperative channel is 2 weeks. It would be stupid of the developers not to put this feature, making it possible for your coins to be locked forever. I would suggest that the person opening the channel should be able to choose how long the minimum time out is as long as it is not less than 24 hours. I believe that would be better.
if the locktime was 2 weeks thats only 2016 offchain payments are allowed
if the locktime was 24 hours thats only 144 offchain payments are allowed,
ill explain
EG imagine we are at block 450,000 right now
make a TX with 24 hour locktime = 450,144
make a 'payment' offchain, locktime = 450,143 (to keep newest relevant)
make a 'payment' offchain, locktime = 450,142 (to keep newest relevant)
make a 'payment' offchain, locktime = 450,142 (to keep newest relevant)
issues
1) not unlimited.
2) if you make 140 payments in 30 minutes (current block 450,003 - payment lock now reduced to 450,004)you have to close channel and broadcast newest payment quick before previous tx become able to release funds
3) you and peer go offline/sleep. then its a game of who wakes up first and transmits the best tx in their favour, that has passed the timelock.
4) it is not a trustless system, it is a system based on mutual agreement.
atleast talking about the flaws will help develop solutions or users knowing the limitations to make smart choices about how when and why they would use it. rather then pretend its all utopia and every tx should be done on it, always and forever
I meant to say is that the lock out time only when there is an uncooperative channel is 2 weeks. Otherwise the channel can remain open as long as the individual at the other end is cooperative.
As for item no. 4 in your post, I agree the system is not trustless but it is better than what something like the Ripple network is proposing. Ripple is all depending on trust that a gateway will not go away with your money. For me it is good to explore all possible avenues for scalabilty. Make the hard fork to bigger blocks the last resort because it is risky.