<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 4:36 AM ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Some minor comments:<br></div><div><br></div><div>1.  You mentioned some impure operations outside of core Simplicity.  Possibly `witness`, and maybe the equivalent of `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVERIFY`?  Are there others?  For my mind, it seems the "impurity" here would become pure once a specific transaction is committed to; my understanding is that Bitcoin SCRIPT itself is "pure" in that sense. (of course, if your input is the entire universe, every program is pure, since it simply outputs a different configuration of the entire universe)<br></div></blockquote><div><br></div><div>The assertion combinators, assertl, and assertr, are impure because they can "output" failure, but this possibility isn't reflected in the expression's type.  The various blockchain primitives, such those given in Section 4.4.1 of the technical report, are impure because their output depends on the transaction context in which the Simplicity program is being evaluated within, but that input isn't reflected in the expression's type.  That is what it means to be impure.  The witness combinator isn't impure; it's contents are simply malleable.<br></div><div><br></div><div>However, as you note, Simplicity's program evaluation is encapsulated with limited side effects.  It cannot write to disk or access the network etc. It's semantics are purely a function of the transaction data (see Section 4.5).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>2.  It seems to me that most of the savings with common sub-expressions is with transporting the program. Which is important because block size limit.<br></div></blockquote><div><br></div><div>More or less.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>3.  From what I understand, effectively each fullnode still executes the program to confirm it completes without violating any assertions.<br></div></blockquote><div><br></div><div>That's right. <br></div></div></div>