From: "Russell O'Connor" <roconnor@blockstream•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks
Date: Tue, 22 Mar 2022 12:28:21 -0400 [thread overview]
Message-ID: <CAMZUoKnC0f=FCjSa9oNMhXob+P6OaMdzUKWbhAMty2Xub-40TA@mail.gmail.com> (raw)
In-Reply-To: <e4r4E0AYzZzkVQp67yxIG-fBBBH8rNrl-MtM7kJXoAsDT_bBSt6gXs_ukw6bBL4845s0OPkrIRjIk54hkQP_pL8X4A--1GFtYcGAl2bW_gs=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
Thanks for the clarification.
You don't think referring to the microcode via its hash, effectively using
32-byte encoding of opcodes, is still rather long winded?
On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Russell,
>
> > Setting aside my thoughts that something like Simplicity would make a
> better platform than Bitcoin Script (due to expression operating on a more
> narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there
> is an issue with namespace management.
> >
> > If I understand correctly, your implication was that once opcodes are
> redefined by an OP_RETURN transaction, subsequent transactions of that
> opcode refer to the new microtransaction. But then we have a race
> condition between people submitting transactions expecting the outputs to
> refer to the old code and having their code redefined by the time they do
> get confirmed (or worse having them reorged).
>
> No, use of specific microcodes is opt-in: you have to use a specific
> `0xce` Tapscript version, ***and*** refer to the microcode you want to use
> via the hash of the microcode.
>
> The only race condition is reorging out a newly-defined microcode.
> This can be avoided by waiting for deep confirmation of a newly-defined
> microcode before actually using it.
>
> But once the microcode introduction outpoint of a particular microcode has
> been deeply confirmed, then your Tapscript can refer to the microcode, and
> its meaning does not change.
>
> Fullnodes may need to maintain multiple microcodes, which is why creating
> new microcodes is expensive; they not only require JIT compilation, they
> also require that fullnodes keep an index that cannot have items deleted.
>
>
> The advantage of the microcode scheme is that the size of the SCRIPT can
> be used as a proxy for CPU load ---- just as it is done for current Bitcoin
> SCRIPT.
> As long as the number of `UOP_` micro-opcodes that an `OP_` code can
> expand to is bounded, and we avoid looping constructs, then the CPU load is
> also bounded and the size of the SCRIPT approximates the amount of
> processing needed, thus microcode does not require a softfork to modify
> weight calculations in the future.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 2641 bytes --]
next prev parent reply other threads:[~2022-03-22 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 5:37 ZmnSCPxj
2022-03-22 15:08 ` Russell O'Connor
2022-03-22 16:22 ` ZmnSCPxj
2022-03-22 16:28 ` Russell O'Connor [this message]
2022-03-22 16:39 ` ZmnSCPxj
2022-03-22 16:47 ` ZmnSCPxj
2022-03-22 23:11 ` Anthony Towns
2022-03-23 0:20 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZUoKnC0f=FCjSa9oNMhXob+P6OaMdzUKWbhAMty2Xub-40TA@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox