Not really, no. Lightning is still payments, multi-party and multi-hop. If the entire realm of Blockchain and smart contract technology was restricted to just payments, well I suppose that would be something. But far short of the total revolution of societal structure that was promised. I personally wouldn’t care to work on it if that was the case. Lightning is an implementation of distributed payments. Smart contracts are an implementation of decentralized law.
Your link to the mailing list thread describes essentially the same approach that bitcoin has for dealing with lock times. I would not normally describe this as “scriptless scripts,” which I have understood to me using the signing operation itself to achieve some goal that would otherwise be done in script. The locktime here is still enforced by special cased code of the consensus algorithm. If the number of things you want to do are fixed and enumerable then I suppose this is a valid approach. But it does not allow for general, arbitrary, future-defined constraints.
To give a concrete, simple example: show me how to do a return peg validation on scriptless scripts. If it can’t even do that, it is not a replacement for scripts.
The manual way. Validate SPV inclusion proofs using CAT, hash opcodes, bignum addition, etc. To be practical it requires block header commitments, but there are other reasons for wanting that. You also need relative locktime, which original bitcoin did not have. But that should be all that is required to be added. Other commonly cited things like Merkle branch verification opcodes just make the script more compact, or get around the fact that some required opcodes were later disabled and/or restricted from use with bignums.
Re: bitcoin vs. ethereum, the bitcoin community pre-ethereum was very invested in the idea of decentralizing all the things. I remember: I was there and part of that history. But over time people interested in more than just payments or the bitcoin asset have left or switched to ethereum. Originally expressive smart contracting was very much in scope.
Verifying cumulative diff requires verifying possibly thousands of headers (all those between peg out and peg in), which is a completely impractical amount of witness data for one script.
Committing headers in Merkle tree form or skip lists allow for logarithmic reduction in that number, as was worked out in the (2014?) sidechains whitepaper. 10’s of headers would be doable.
Beyond requiring intrusive changes to Bitcoin like header commitments, and still needing dozen-KB scripts for pegs, it also limits properties of the sidechain. For instance, if the latter wants to use a memory-hard PoW like Cuckoo Cycle, I don't see how Bitcoin script (which cannot even loop) could verify a cycle in a pseudorandom graph.
I could argue that there’s no reason for any proof of work other than sha256 as these side chains should be merge mining, but we’re way off in a tangent thread.
The point is that smart contracts actually do something other than “authorize payment”, and fancy Schnorr signing modes don’t come close to replicating those capabilities.
And so long as there is a need for a programmable verification architecture, Forth-like languages are prttty ideal.
Your link to the mailing list thread describes essentially the same approach that bitcoin has for dealing with lock times. I would not normally describe this as “scriptless scripts,” which I have understood to me using the signing operation itself to achieve some goal that would otherwise be done in script. The locktime here is still enforced by special cased code of the consensus algorithm. If the number of things you want to do are fixed and enumerable then I suppose this is a valid approach. But it does not allow for general, arbitrary, future-defined constraints.
To give a concrete, simple example: show me how to do a return peg validation on scriptless scripts. If it can’t even do that, it is not a replacement for scripts.