Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E048CF5 for ; Tue, 31 Oct 2017 21:01:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 94873F8 for ; Tue, 31 Oct 2017 21:01:07 +0000 (UTC) Received: by mail-ua0-f178.google.com with SMTP id i35so228584uah.9 for ; Tue, 31 Oct 2017 14:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lyQhnx84yEaBISk3aFEJg6e4HzxRnqThYkUbHeRRRuE=; b=iY8jq3Z9yCfyEEaZ//S95JhVj+NZMxkh0WP+pGyS3xYEC2LMs4gHubN7RnWBBBx05T wuMbCbyRRM2LUfiCANHxtystmMfRZ/kKBX09uYad9jX2cCtnkagYV3Zr2GekVB8OZCpk pjiZyv8V4kZM74mpavW0W0kY528l35UOe7iDUjK+ii++7zk2gw09EJ6CEGJOC3mPN3Q5 uA5fFuUgemOo4ltxoFWjdInGA3qyd1tfdBEifdzIDxjL8X0MNUUl0ZJz5L9rLPFljWhn DDsaFZk83/hGE2UQCLo1ITkUxP6cp9omq/4aWRAEU7d6iQVt/p58wBOGOnHLz9evFI/B 1p8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lyQhnx84yEaBISk3aFEJg6e4HzxRnqThYkUbHeRRRuE=; b=WD/SR3mBBSmySdASEowMn+ehcFDyyYVpLRS3yg6Tzcr0wXsvFu1StJH9E4i3sjk0A+ ZO+fOpjkTP8KF2lrjLlGTLDJgtn32gWZ7NdC4o/rvOwl6r14NwR06nBINuBwV+qRZWS/ D9FuuCGuCGhcap863PreL2WFEnJHjoA7TjwXOgLcCPthdZGNQyFuuCY1KTcskcqqSSfd HCu9ocUmdARtTamb+IZY3g3Gmcww/m2MgvKlues6QH45mO8ZD0x/KzWhShUDNm9DVnQ6 LVr0ya/P5nBypgi3XcRqqopMLcM3j/mMIB0hjLg1Geu1++Wq60mzzkFDnnUmXSRyqjQn gxEQ== X-Gm-Message-State: AMCzsaV79Zvr/5zsYHwLsmZpVfsGP2/c/zdRGxwESHLLVvwJj4qu6TbX 9+WzZJFOZZragQ+Wx8ynQyXxc57s6XaD077ZRbyyRg== X-Google-Smtp-Source: ABhQp+RNzhGFxO9/8oMhYp4kWA4EUAarHfQbwjIMZYSond4ztAzZuGZKcbH3ffXWCcXlCBVKh9BqHzoikSJ0tQvFYVY= X-Received: by 10.176.80.3 with SMTP id b3mr2854011uaa.1.1509483666561; Tue, 31 Oct 2017 14:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.73.202 with HTTP; Tue, 31 Oct 2017 14:01:05 -0700 (PDT) Received: by 10.176.73.202 with HTTP; Tue, 31 Oct 2017 14:01:05 -0700 (PDT) In-Reply-To: References: From: "Russell O'Connor" Date: Tue, 31 Oct 2017 17:01:05 -0400 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary="94eb2c18ee3ebd6c6d055cde0d4b" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Simplicity: An alternative to Script X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:01:10 -0000 --94eb2c18ee3ebd6c6d055cde0d4b Content-Type: text/plain; charset="UTF-8" That approach is worth considering. However there is a wrinkle that Simplicity's denotational semantics doesn't imply an order of operations. For example, if one half of a pair contains a assertion failure (fail-closed), and the other half contains a unknown jet (fail-open), then does the program succeed or fail? This could be solved by providing an order of operations; however I fear that will complicate formal reasoning about Simplicity expressions. Formal reasoning is hard enough as is and I hesitate to complicate the semantics in ways that make formal reasoning harder still. On Oct 31, 2017 15:47, "Mark Friedenbach" wrote: Nit, but if you go down that specific path I would suggest making just the jet itself fail-open. That way you are not so limited in requiring validation of the full contract -- one party can verify simply that whatever condition they care about holds on reaching that part of the contract. E.g. maybe their signature is needed at the top level, and then they don't care what further restrictions are placed. On Tue, Oct 31, 2017 at 1:38 PM, Russell O'Connor via bitcoin-dev wrote: > (sorry, I forgot to reply-all earlier) > > The very short answer to this question is that I plan on using Luke's > fail-success-on-unknown-operation in Simplicity. This is something that > isn't detailed at all in the paper. > > The plan is that discounted jets will be explicitly labeled as jets in the > commitment. If you can provide a Merkle path from the root to a node that > is an explicit jet, but that jet isn't among the finite number of known > discounted jets, then the script is automatically successful (making it > anyone-can-spend). When new jets are wanted they can be soft-forked into > the protocol (for example if we get a suitable quantum-resistant digital > signature scheme) and the list of known discounted jets grows. Old nodes > get a merkle path to the new jet, which they view as an unknown jet, and > allow the transaction as a anyone-can-spend transaction. New nodes see a > regular Simplicity redemption. (I haven't worked out the details of how the > P2P protocol will negotiate with old nodes, but I don't forsee any > problems.) > > Note that this implies that you should never participate in any Simplicity > contract where you don't get access to the entire source code of all > branches to check that it doesn't have an unknown jet. > > On Mon, Oct 30, 2017 at 5:42 PM, Matt Corallo > wrote: >> >> 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. >> >> Is there some insight I'm missing here? >> >> Matt >> >> >> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitcoin-dev >> wrote: >>> >>> I've been working on the design and implementation of an alternative to >>> Bitcoin Script, which I call Simplicity. Today, I am presenting my design >>> at the PLAS 2017 Workshop on Programming Languages and Analysis for >>> Security. You find a copy of my Simplicity paper at >>> https://blockstream.com/simplicity.pdf >>> >>> Simplicity is a low-level, typed, functional, native MAST language where >>> programs are built from basic combinators. Like Bitcoin Script, Simplicity >>> is designed to operate at the consensus layer. While one can write >>> Simplicity by hand, it is expected to be the target of one, or multiple, >>> front-end languages. >>> >>> 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. >>> >>> 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. 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. >>> >>> Simplicity comes with easy to compute static analyses that can compute >>> bounds on the space and time resources needed for evaluation. 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. >>> >>> As a native MAST language, unused branches of Simplicity programs are >>> pruned at redemption time. This enhances privacy, reduces the block weight >>> used, and can reduce space and time resource costs needed for evaluation. >>> >>> To make Simplicity practical, jets replace common Simplicity expressions >>> (identified by their MAST root) and directly implement them with C code. I >>> anticipate developing a broad set of useful jets covering arithmetic >>> operations, elliptic curve operations, and cryptographic operations >>> including hashing and digital signature validation. >>> >>> The paper I am presenting at PLAS describes only the foundation of the >>> Simplicity language. The final design includes extensions not covered in >>> the paper, including >>> >>> - full convent support, allowing access to all transaction data. >>> - support for signature aggregation. >>> - support for delegation. >>> >>> Simplicity is still in a research and development phase. I'm working to >>> produce a bare-bones SDK that will include >>> >>> - the formal semantics and correctness proofs in Coq >>> - a Haskell implementation for constructing Simplicity programs >>> - and a C interpreter for Simplicity. >>> >>> After an SDK is complete the next step will be making Simplicity >>> available in the Elements project 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. >>> >>> 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. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c18ee3ebd6c6d055cde0d4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That approach is worth considering.=C2=A0 However th= ere is a wrinkle that Simplicity's denotational semantics doesn't i= mply an order of operations.=C2=A0 For example, if one half of a pair conta= ins a assertion failure (fail-closed), and the other half contains a unknow= n jet (fail-open), then does the program succeed or fail?
=
This could be solved by providing an order of o= perations; however I fear that will complicate formal reasoning about Simpl= icity expressions.=C2=A0 Formal reasoning is hard enough as is and I hesita= te to complicate the semantics in ways that make formal reasoning harder st= ill.


On = Oct 31, 2017 15:47, "Mark Friedenbach" <mark@friedenbach.org> wrote:
Nit, but if you go down that specific path I wo= uld suggest making just
the jet itself fail-open. That way you are not so limited in requiring
validation of the full contract -- one party can verify simply that
whatever condition they care about holds on reaching that part of the
contract. E.g. maybe their signature is needed at the top level, and
then they don't care what further restrictions are placed.

On Tue, Oct 31, 2017 at 1:38 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> (sorry, I forgot to reply-all earlier)
>
> The very short answer to this question is that I plan on using Luke= 9;s
> fail-success-on-unknown-operation in Simplicity.=C2=A0 This is so= mething that
> isn't detailed at all in the paper.
>
> The plan is that discounted jets will be explicitly labeled as jets in= the
> commitment.=C2=A0 If you can provide a Merkle path from the root to a = node that
> is an explicit jet, but that jet isn't among the finite number of = known
> discounted jets, then the script is automatically successful (making i= t
> anyone-can-spend).=C2=A0 When new jets are wanted they can be soft-for= ked into
> the protocol (for example if we get a suitable quantum-resistant digit= al
> signature scheme) and the list of known discounted jets grows.=C2=A0 O= ld nodes
> get a merkle path to the new jet, which they view as an unknown jet, a= nd
> allow the transaction as a anyone-can-spend transaction.=C2=A0 New nod= es see a
> regular Simplicity redemption.=C2=A0 (I haven't worked out the det= ails of how the
> P2P protocol will negotiate with old nodes, but I don't forsee any=
> problems.)
>
> Note that this implies that you should never participate in any Simpli= city
> contract where you don't get access to the entire source code of a= ll
> branches to check that it doesn't have an unknown jet.
>
> On Mon, Oct 30, 2017 at 5:42 PM, Matt Corallo <lf-lists@mattcorallo.com>
> wrote:
>>
>> I admittedly haven't had a chance to read the paper in full de= tails, but I
>> was curious how you propose dealing with "jets" in somet= hing like Bitcoin.
>> AFAIU, other similar systems are left doing hard-forks to reduce t= he
>> sigops/weight/fee-cost of transactions every time they want to add= useful
>> optimized drop-ins. For obvious reasons, this seems rather impract= ical and a
>> potentially critical barrier to adoption of such optimized drop-in= s, which I
>> imagine would be required to do any new cryptographic algorithms d= ue to the
>> significant fee cost of interpreting such things.
>>
>> Is there some insight I'm missing here?
>>
>> Matt
>>
>>
>> On October 30, 2017 11:22:20 AM EDT, Russell O'Connor via bitc= oin-dev
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>>>
>>> I've been working on the design and implementation of an a= lternative to
>>> Bitcoin Script, which I call Simplicity.=C2=A0 Today, I am pre= senting my design
>>> at the PLAS 2017 Workshop on Programming Languages and Analysi= s for
>>> Security.=C2=A0 You find a copy of my Simplicity paper at
>>> https://blockstream.com/simplicity.pdf >>>
>>> Simplicity is a low-level, typed, functional, native MAST lang= uage where
>>> programs are built from basic combinators.=C2=A0 Like Bitcoin = Script, Simplicity
>>> is designed to operate at the consensus layer.=C2=A0 While one= can write
>>> Simplicity by hand, it is expected to be the target of one, or= multiple,
>>> front-end languages.
>>>
>>> Simplicity comes with formal denotational semantics (i.e. sema= ntics of
>>> what programs compute) and formal operational semantics (i.e. = semantics of
>>> how programs compute). These are both formalized in the Coq pr= oof assistant
>>> and proven equivalent.
>>>
>>> Formal denotational semantics are of limited value unless one = can use
>>> them in practice to reason about programs. I've used Simpl= icity's formal
>>> semantics to prove correct an implementation of the SHA-256 co= mpression
>>> function written in Simplicity.=C2=A0 I have also implemented = a variant of ECDSA
>>> signature verification in Simplicity, and plan to formally val= idate its
>>> correctness along with the associated elliptic curve operation= s.
>>>
>>> Simplicity comes with easy to compute static analyses that can= compute
>>> bounds on the space and time resources needed for evaluation.= =C2=A0 This is
>>> important for both node operators, so that the costs are knows= before
>>> evaluation, and for designing Simplicity programs, so that sma= rt-contract
>>> participants can know the costs of their contract before commi= tting to it.
>>>
>>> As a native MAST language, unused branches of Simplicity progr= ams are
>>> pruned at redemption time.=C2=A0 This enhances privacy, reduce= s the block weight
>>> used, and can reduce space and time resource costs needed for = evaluation.
>>>
>>> To make Simplicity practical, jets replace common Simplicity e= xpressions
>>> (identified by their MAST root) and directly implement them wi= th C code.=C2=A0 I
>>> anticipate developing a broad set of useful jets covering arit= hmetic
>>> operations, elliptic curve operations, and cryptographic opera= tions
>>> including hashing and digital signature validation.
>>>
>>> The paper I am presenting at PLAS describes only the foundatio= n of the
>>> Simplicity language.=C2=A0 The final design includes extension= s not covered in
>>> the paper, including
>>>
>>> - full convent support, allowing access to all transaction dat= a.
>>> - support for signature aggregation.
>>> - support for delegation.
>>>
>>> Simplicity is still in a research and development phase.=C2=A0= I'm working to
>>> produce a bare-bones SDK that will include
>>>
>>> - the formal semantics and correctness proofs in Coq
>>> - a Haskell implementation for constructing Simplicity program= s
>>> - and a C interpreter for Simplicity.
>>>
>>> After an SDK is complete the next step will be making Simplici= ty
>>> available in the Elements project so that anyone can start exp= erimenting
>>> with Simplicity in sidechains. Only after extensive vetting wo= uld it be
>>> suitable to consider Simplicity for inclusion in Bitcoin.
>>>
>>> Simplicity has a long ways to go still, and this work is not i= ntended to
>>> delay consideration of the various Merkelized Script proposals= that are
>>> currently ongoing.
>
>
>
> ________________________________= _______________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c18ee3ebd6c6d055cde0d4b--