It's interesting the use of nibbles (4-bit words) instead of 32-bit words to operate. That's perfect for tables involving two 4-bit operands (AND, OR, XOR, SHIFT, etc.).
Why create a SHA-256 implementation in script if there is a OP_SHA256 opcode?
Because Bitcoin script cannot expand the OP_SHA256 output value (32 bytes) into individual bytes in the stack. Therefore, OP_SHA256 cannot be used to check properties of the input and output inside the script. This prevents the use of OP_SHA256 to verify Lamport/Winternitz signatures.
Why create a SHA-256 implementation in script if there is a OP_SHA256 opcode?
Because Bitcoin script cannot expand the OP_SHA256 output value (32 bytes) into individual bytes in the stack. Therefore, OP_SHA256 cannot be used to check properties of the input and output inside the script. This prevents the use of OP_SHA256 to verify Lamport/Winternitz signatures.
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.
