Date: Tue, 22 Mar 2022 16:39:10 +0000
To: Russell O'Connor <roconnor@blockstream.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <b44RnTZqVC01psPp8Iijmj2oGLcm7CnG56UaT5xEvtNkVVOfK4YAka_jf-zey7_Kkou7ewNWbGx9sBDoF3Fu9OA2aL2FCVY4u0ZI6geOCpU=@protonmail.com>
In-Reply-To: <CAMZUoKnC0f=FCjSa9oNMhXob+P6OaMdzUKWbhAMty2Xub-40TA@mail.gmail.com>
References: <NGFW5p2Gl4t6AqL2E29THMT5DbppMJlB6bdUE6nxAdMajxeFcoRNdt5axNLql08EoyIMsBgZHHHYt_MiITZwzyGZIz0iFX4vaKIYrVV2QhU=@protonmail.com>
 <CAMZUoK=TzOFfMFwNw6gjHtu2EeEPhyL9AjqLS-T=wphc905_JA@mail.gmail.com>
 <e4r4E0AYzZzkVQp67yxIG-fBBBH8rNrl-MtM7kJXoAsDT_bBSt6gXs_ukw6bBL4845s0OPkrIRjIk54hkQP_pL8X4A--1GFtYcGAl2bW_gs=@protonmail.com>
 <CAMZUoKnC0f=FCjSa9oNMhXob+P6OaMdzUKWbhAMty2Xub-40TA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets
	Without Softforks
Precedence: list

Good morning Russell,

> Thanks for the clarification.
>
> You don't think referring to the microcode via its hash, effectively usin=
g 32-byte encoding of opcodes, is still rather long winded?

A microcode is a *mapping* of `OP_` codes to a variable-length sequence of =
`UOP_` micro-opcodes.
So a microcode hash refers to an entire language of redefined `OP_` codes, =
not each individual opcode in the language.

If it costs 1 Bitcoin to create a new microcode, then there are only 21 mil=
lion possible microcodes, and I think about 50 bits of hash is sufficient t=
o specify those with low probability of collision.
We could use a 20-byte RIPEMD . SHA256 instead for 160 bits, that should be=
 more than sufficient with enough margin.
Though perhaps it is now easier to deliberately attack...

Also, if you have a common SCRIPT whose non-`OP_PUSH` opcodes are more than=
 say 32 + 1 bytes (or 20 + 1 if using RIPEMD), and you can fit their equiva=
lent `UOP_` codes into the max limit for a *single* opcode, you can save by=
tes by redefining some random `OP_` code into the sequence of all the `UOP_=
` codes.
You would have a hash reference to the microcode, and a single byte for the=
 actual "SCRIPT" which is just a jet of the entire SCRIPT.
Users of multiple *different* such SCRIPTs can band together to define a si=
ngle microcode, mapping their SCRIPTs to different `OP_` codes and sharing =
the cost of defining the new microcode that shortens all their SCRIPTs.

Regards,
ZmnSCPxj