[Simplicity] Translating a Simplicity Dialect to MAST-enabled Bitcoin SCRIPT

[Russell O'Connor]

On Thu, Dec 6, 2018 at 4:36 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Some minor comments:
>
> 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)
>

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.

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).


> 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.
>

More or less.


> 3.  From what I understand, effectively each fullnode still executes the
> program to confirm it completes without violating any assertions.
>

That's right.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/simplicity/attachments/20181206/89ca9984/attachment.html>