Bitcoin Forum

Martin from FairgateLabs created a Blake3 implementation in Bitcoin script. This is the shortest hash function ever implemented in script (only 45K bytes or 11.2K vbytes in a Taproot script).

Why implement a hash function when we have OP_HASH and OP_HASH256 and other opcodes ? Because Bitcoin script currently does not allow the manipulation of individual bytes of the hash digests produced by OP_HASH, so we cannot implement Lamport or Winternitz signatures based on existing opcodes.
Having signatures for arbitrary messages (not only the transaction) is essential for proving systems like BitVMX.org (http://BitVMX.org). The shortest the code, the cheaper the onchain disputes.
(BitVMX is a optimistic proving system for arbitrary programs, based on a virtual CPU. It does not require any hard-fork or soft-fork to Bitcoin.)

Specs


The new implementation is compared with the previous one that existed in BitVM. These are the numbers:

Bytes Hashed   Number of blocks   Original Size   New Implementation Size   Improvement from original
64   1   103k   45k   55.60%
80   2   206k   91k   55.72%

Comparing the max stack height usage:

Bytes   Blocks   Original   New New stack-optimized Size
64   1   384   671   550   47K
80   2   448   779   678   95K

You can take a look at the PR here: https://github.com/BitVM/BitVM/pull/67

Also you can learn more about BitVMX from its paper: https://bitvmx.org/files/bitvmx-whitepaper.pdf. Or you can comment in this thread: https://bitcointalk.org/index.php?topic=5494208.0

Again, as I wrote before (https://bitcointalk.org/index.php?topic=5494410.msg63999121#msg63999121), sounds like yet another reason to enable OP_CAT. And I wonder, if redirecting some efforts put into writing cat-less scripts, into activating OP_CAT instead, would make life easier.

Because that OP_CAT BIP needs more examples and use cases. Which means, that filling this gap could push things forward.