<div>Good morning Russell,<br></div><div><br></div><div>Thank you very much your explanation of this plan.<br></div><div><br></div><div>However, I wonder if it would generally be wiser, if we consider to use Bitcoin SCRIPT as execution target for a Simplicity dialect, to improve privacy and fungibility by not immediately advertising that a UTXO uses Simplicity.<br></div><div>A separate SegWit version would immediately evidence use of Simplicity, with high probability.<br></div><div><br></div><div>Of course, it is likely that even Simplicity-derived SCRIPT will look very different from what a human-level sentience might create.<br></div><div>We could hope for the invention of a mythical "sufficiently smart compiler" that will optimize the generated SCRIPT to nearer to what a human-level sentinece might create by hand, but that is unlikely.<br></div><div><br></div><div>Finally, we also need to re-enable OP_CAT, OP_AND, and O_RSHIFT.<br></div><div><br></div><div>Which leads to another topic.<br></div><div>Current Bitcoin SCRIPT disables many operations, like OP_CAT, OP_AND, OP_RSHIFT.<br></div><div>These operations are needed in Bitcoin SCRIPT in order to emulate many of the basic operations of the Bit Machine currently targeted by the Simplicity.<br></div><div>Even if these operations are re-enabled, it is likely that they will be imposed some limits to prevent the issues that caused them to be disabled in the first place.<br></div><div>Thus it seems to me that a Bit Machine implementation would also require similar limits to the size of types, as it seems likely to me that a human-level sentience can manually write Bit Machine code that would massively increase memory consumption.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><br></div><div class="protonmail_signature_block-proton">Sent with <a target="_blank" href="https://protonmail.com">ProtonMail</a> Secure Email.<br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Friday, November 30, 2018 6:19 AM, Russell O'Connor <roconnor@blockstream.io> wrote:<br></div><div> <br></div><blockquote type="cite" class="protonmail_quote"><div dir="ltr"><div>Hi ZmnSCPxj,<br></div><div><br></div><div>(It seems I wasn't subscribed to my own list, so I've manually quoted your post below)<br></div><div><br></div><div>Should the Bitcoin community be interested in incorporating Simplicity, it would be done by utilizing the Segwit version scheme, and/or any upcoming Taproot version scheme.<br></div><div><br></div><div>Segwit leaves completely open the interpretation of witness data for future versions, and does not require that the data be in some form of Bitcoin Script.  So it is possible, for example, to pass serialized Simplicity programs through Segwit's data blob, have it interpreted by a Simplicity interpreter, and not deal with Bitcoin Script at all (beyond the specific form of the scriptPubKey that <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program">BIP141</a> mandates).<br></div><div><br></div><div>I do want to emphasize that we are a long way from even considering Simplicity for Bitcoin.  Such a radical update would need a huge amount of vetting before it would be acceptable for Bitcoin, if ever.  The best way to do that vetting is by running Simplicity in a sidechain, which is why I'm aiming to put Simplicity into the Elements platform first, then into Blockstream's Liquid network.  Even so, there still remains a lot of work to do before Simplicity can be incorporated into Elements.<br></div><div><br></div><div>-- <br></div><div>Russell<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre>Good morning list,

From my understanding, Simplicity describes a family of languages which are effectively total (provably terminating) and not partial (may crash).
This prevents arbitrary looping, requiring bounds on recursion.

Now, due to the fact that total languages assuredly terminate, it is possible to completely analyze a program written in a total language.
In particular, it is possible to speculatively execute every possible branch of a total program.

If we import certain Bitcoin SCRIPT operations (signature checks and such) as primitives (jets?) of a Simplicity dialect, it seems to me possible to translate each possible execution of a total program written in this Simplicity dialect to a simple branchless Bitcoin SCRIPT.
Scripts would verify that the correct branch is being executed with given inputs, by use of `OP_VERIFY` on operations on those inputs.
(although we probably need to reenable some of the bit-manipulation operations in Bitcoin SCRIPT)
We can then commit all such SCRIPTs in a single MAST, or possibly just store each SCRIPT and a Graftroot signature (Graftroot has the tremendous advantage of low overhead, requiring O(1) information to select a branch, compared to O(log N) for MAST).

Then a Simplicity interpreter can simply execute using given inputs, and determine which of the branches will run, and provide the SegWit `witness` stack to claim a TXO.

Am I right in thinking that this is the eventual way that Simplicity will reach the Bitcoin blockchain?

Finally: first post.

Regards,
ZmnSCPxj<br></pre></blockquote></div></blockquote><div><br></div>