SHA-256 coding in Bitcoin script under 400K vbytes

So, Martin Jonas from the BitVMX team whipped up a SHA-256 code using Bitcoin script that can hash 64 bytes, and it's compact enough to fit into a standard taproot script. The biggest hurdle is the limit on the script stack (1000 elements). If the stack were bigger, we could probably reduce it to around 100 Kb. This is part of the BitVM2 project being implemented in Rust. It's pretty cool how they're using nibbles (4-bit words) instead of the usual 32-bit words for operations. This is great for working with tables that have two 4-bit operands like AND, OR, XOR, SHIFT, etc. So why bother creating a SHA-256 version in script when there's already an OP_SHA256 opcode? Well, the deal is that Bitcoin script can't break down the OP_SHA256 output (32 bytes) into single bytes in the stack. Because of this, you can't use OP_SHA256 to check the characteristics of input and output within the script. This makes it impossible to use OP_SHA256 for verifying Lamport/Winternitz signatures. By the way, Martin’s working at fairgate.io and is also involved with BitVMX.org.

I think people should support OP_CAT soft-fork, because that single opcode can solve a lot of issues there.

I support OP_CAT, but Bitcoin L2s need more decentralized bridges now. We'll develop BitVMX with optional support of OP_CAT, so that we can make use of OP_CAT if/when it is activated.

I am not familiar with those kinds of signatures so let me ask you a question: How would the SHA256 output being split into nibbles help to verify Lamport or WInternitz signatures? Also what is the use case for those two kinds of signatures, and how does it compare to something like ECDSA (which is recoverable) or maybe Schnorr even. I do know that having the ability to verify signatures inline of the script is a good thing as CHECKSIG-like opcodes are not going to be introduced anytime soon, so I want to know what kind of things you can do with this.