<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Script versions makes this no longer a hard-fork to do. The script version would implicitly encode which jets are optimized, and what their optimized cost is.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 30, 2017, at 2:42 PM, Matt Corallo via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I admittedly haven't had a chance to read the paper in full details, but I was curious how you propose dealing with "jets" in something like Bitcoin. AFAIU, other similar systems are left doing hard-forks to reduce the sigops/weight/fee-cost of transactions every time they want to add useful optimized drop-ins. For obvious reasons, this seems rather impractical and a potentially critical barrier to adoption of such optimized drop-ins, which I imagine would be required to do any new cryptographic algorithms due to the significant fee cost of interpreting such things.<br class="">
<br class="">
Is there some insight I'm missing here?<br class="">
<br class="">
Matt<br class=""><br class=""><div class="gmail_quote">On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr" class=""><div class="">I've
 been working on the design and implementation of an alternative to 
Bitcoin Script, which I call Simplicity.&nbsp; Today, I am presenting my 
design at the <a href="http://plas2017.cse.buffalo.edu/" target="_blank" class="">PLAS 2017 Workshop</a> on Programming Languages and Analysis for Security.&nbsp; You find a copy of my Simplicity paper at <a href="https://blockstream.com/simplicity.pdf" target="_blank" class="">https://blockstream.com/<wbr class="">simplicity.pdf</a><br class=""></div><div class=""><br class=""></div>Simplicity
 is a low-level, typed, functional, native MAST language where programs 
are built from basic combinators.&nbsp; Like Bitcoin Script, Simplicity is 
designed to operate at the consensus layer.&nbsp; While one can write 
Simplicity by hand, it is expected to be the target of one, or multiple,
 front-end languages.<br class=""><div class=""><br class=""></div><div class="">Simplicity comes with
 formal denotational semantics (i.e. semantics of what programs compute)
 and formal operational semantics (i.e. semantics of how programs 
compute). These are both formalized in the Coq proof assistant and 
proven equivalent.<br class=""><br class=""></div>Formal denotational semantics are of 
limited value unless one can use them in practice to reason about 
programs. I've used Simplicity's formal semantics to prove correct an 
implementation of the SHA-256 compression function written in 
Simplicity.&nbsp; I have also implemented a variant of ECDSA signature 
verification in Simplicity, and plan to formally validate its 
correctness along with the associated elliptic curve operations.<br class=""><div class=""><br class="">Simplicity
 comes with easy to compute static analyses that can compute bounds on 
the space and time resources needed for evaluation.&nbsp; This is important 
for both node operators, so that the costs are knows before evaluation, 
and for designing Simplicity programs, so that smart-contract 
participants can know the costs of their contract before committing to 
it.</div><div class=""><br class=""></div><div class="">As a native MAST language, unused branches 
of Simplicity programs are pruned at redemption time.&nbsp; This enhances 
privacy, reduces the block weight used, and can reduce space and time 
resource costs needed for evaluation.</div><div class=""><br class=""></div><div class="">To make 
Simplicity practical, jets replace common Simplicity expressions 
(identified by their MAST root) and directly implement them with C 
code.&nbsp; I anticipate developing a broad set of useful jets covering 
arithmetic operations, elliptic curve operations, and cryptographic 
operations including hashing and digital signature validation.<br class=""></div><div class=""><br class=""></div><div class="">The
 paper I am presenting at PLAS describes only the foundation of the 
Simplicity language.&nbsp; The final design includes extensions not covered 
in the paper, including</div><div class=""><br class=""></div><div class="">- full convent support, allowing access to all transaction data.</div><div class="">- support for signature aggregation.</div><div class="">- support for delegation.</div><div class=""><br class=""></div><div class="">Simplicity is still in a research and development phase.&nbsp; I'm working to produce a bare-bones SDK that will include <br class=""></div><div class=""><br class=""></div><div class="">- the formal semantics and correctness proofs in Coq</div><div class="">- a Haskell implementation for constructing Simplicity programs</div><div class="">- and a C interpreter for Simplicity.<br class=""></div><div class=""><br class=""></div><div class="">After an SDK is complete the next step will be making Simplicity available in the <a href="https://elementsproject.org/" target="_blank" class="">Elements project</a>
 so that anyone can start experimenting with Simplicity in sidechains. 
Only after extensive vetting would it be suitable to consider Simplicity
 for inclusion in Bitcoin.</div><div class=""><br class=""></div>Simplicity has a 
long ways to go still, and this work is not intended to delay 
consideration of the various Merkelized Script proposals that are 
currently ongoing.</div>
</blockquote></div></div>_______________________________________________<br class="">bitcoin-dev mailing list<br class=""><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a><br class="">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br class=""></div></blockquote></div><br class=""></body></html>