If wait for confirmation then there is no malleability problem
That's the point I'm making: if you don't wait, malleable or not, the tx can be double spent.
That's why malleability in LN is important only for internal (to the channel) transactions and not for opening or closing the channel, where you wait for the usual N confirmations.
That's kind of mindset I don't like, since the more complex it gets, the more time it takes to reach consensus, might from years to decades, but I won't worry about something that happens after I died
I suppose you don't understand what "programmable" means.
If you have consensus for a set of opcodes you do not need any consensus at all for any usage of them: a simple P2PK tx or a multisig with nlocktime or a more complex one gets correctly validated (and thus has full consensus) since the very first Bitcoin release that implemented the used opcodes. You do not need a new consensus for any way you combine their usage (i.e.: the program you write with them).
It's human creativity that find new ways to use those opcodes to create something new and more useful, that's why you can use programs as complex as like the browser you are using right now, programmed (or programmable) with a few basic operations (opcodes) that Alan Turing envisaged decades ago.
The consensus on the working of those basic operations is enough to make any program, ever. (That's what "touring complete" means, btw).
In fact this model has been mostly abandoned by telecom operators years ago, and replaced with fixed monthly rate regardless of usage/quota model. Only a very small percentage traffic are still billed on prepaid card model
You are not understanding the issue: of course operators prefers to bill you a periodic rate, but they can do it only if you are a usual customer of theirs. Prepaid cards were not invented for this purpose, but for managing to offer a service for just one time to a customer, on the fly.
While its usage is dropping because there are more useful alternatives (like using Internet cafes instead of doing long-distance calls), they are all but dead: my wife works in a shop where they still sells a lot of them daily.
Try to explain these to average users and miners (who hold the decision making power for change) and see how long it takes to get them to reach consensus. Previously all the decision making power of code are purely centralized on devs, this have to be abolished as we learned the hard way
Do I need to show you that thanks to softforks, new opcodes like OP_CTLV has been introduced in the network in a very short time without any difficulty at all, and without requesting any consensus by final users? They just had to wait miners to adopt latest bitcoin core version.
We need new opcodes every once a while because Bitcoin scripting language (unlike Ethereum's) is not Turing Complete and hence it can't implement arbitrary complex programs.
Personally I find OP_CTLV and OP_CSV excellent new opcodes that could one day foster Bitcoin usage, so I'm fine they get introduced with a soft fork in place of NOP codes expressly put there for that purpose (extendibility).
But I'm not fine to use a softfork (like Core is pushing) to drastically change the whole scripting capabilities with a whole new set like SegWit.
