> you think people are trying to add scalability... No, people are trying to have usuable smart contracts I thunk they are trying to do both, and I think my proposal is the cheapest way to do both proposed so far, and as a result, also the least spammy. > [they want an] actual smart contract language that is not as awful as BitVM Bitvm allows you to use any smart contract lamguage you want. Normal devs are not expected to write their programs in binary circuits, that's what compilers are for. > [bitvm] forces people to use ZKVMs that are far from water tight I am unfamiliar with this criticism, do you have more details or a link to where I can read more?

No this is not true, every time a withdrawal is attempted with withheld data, everyone will merkle proofs, but many contracts that aren't owned by anyone in particular will also need the entire data in that contract and not just the last utxo. For example if a 100 blocks were created in the sidechain, and each block contained a OP_CCV like state update, these updates could be an append only log, meaning all these updates are necessary (for example these updates could be themselves proposed state updates that only settles after they are enough txns deep, or simply chunks across blocks).. You need all this data to continue the sidechain... And even worse you also wanted to see these updates in a timely manner... You can't just wait till they are dumped on you. So, 1) it is not the sad path of withdrawal with withheld data, proof of publication is necessary in the average case... You don't even need to think of the Defi, even vaults need this. 2) BitVM data carrying suuuuucks... You are most probably going to end up on the average case spending more money and bloating the chain more. You are probably correct if all you are trying to do is replicate Lightning but with many users... I.e just transfer of fungible tokens... But as I said, this doesn't suffice. You are welcome to build it though, it is great that what you are happy with doesn't require new consensus