Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B78B98C for ; Fri, 3 Nov 2017 16:19:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f169.google.com (mail-pf0-f169.google.com [209.85.192.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0900FE3 for ; Fri, 3 Nov 2017 16:19:41 +0000 (UTC) Received: by mail-pf0-f169.google.com with SMTP id b85so2522130pfj.13 for ; Fri, 03 Nov 2017 09:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v297bMamYs1sQXPrXTFMQ0zhgLn82pGEtUrfXkNJTpo=; b=kW9lukfVmXYQgMzB7cahgorK3+ynwdJli7mLHX2UIs/eSZcFcUg02Ly+6GzUJW7sCZ AM2FbalHd2Md6rUk9fLmc7AlH4T78xz2Ed100vxXlWOiBLajOPpw3yh/zxQqi463Qv4B qFWUnCZTf1iLPdyleYLWdvRv5fderEA+08N9fCXo++NR7OZ5SbfD/yWliUvoQ0eFKTId o/oGb9XxNbglOuUmcn8G5p7suHO/zE7sUwXq2Y0OtAxhQR+GZGwZUP61tXoj0G9E1AAK KJ8PvwE3uJ8FR2PwHUzySPr5qzZhb3RpwwSitzpZfJbuhuQOhou+PRxZbsbIWJfdCKul rCDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v297bMamYs1sQXPrXTFMQ0zhgLn82pGEtUrfXkNJTpo=; b=rMszBNf7xzkXpstNFK5FTdGQgEIc1B/UO3RxnFXOM0AMWL2uEn4FGf5zS2xlwYIwiU 8jQnDNfoa+y/RFl0hJWUxT+2bSdCBMVJ9I2oVcgfGBKNXCs69t3PSfPKmq2HKVQ4zwFH EyDJkRes8/4Qv04py4s4n3qeQ+kXu1GkM9a7oDJXzCclhTtZq2RVUCi3px6IoTgMYqCn GgIOGSwA+7eLpP3M7M+JpPzIHhER9oLKYWjY8NZQO9mLqvoe3svRvCW9xTXqZX18t3uC KYhOkLqsAVw+kx9y76GAxbxQaRoYosYebMdHE8zVWPlQ4wfZLl8Tf0XmbAEazZWqXKPw wQ1Q== X-Gm-Message-State: AMCzsaV+PTMB4gZzcw4Sj7ZlcCvctm+bUGX2dzkh4VW4syc+fcvcXP2o OH1C+zZysUiLCuv5XhYHr/gaM+yStVs= X-Google-Smtp-Source: ABhQp+QkUUiB/8veGpOWaG8qt7X7+PB2ywDTJIXEWzYW7DnoS/uQh9BpTCGl99ow5/WUN5wvNBJcdQ== X-Received: by 10.99.109.73 with SMTP id i70mr7473916pgc.177.1509725981341; Fri, 03 Nov 2017 09:19:41 -0700 (PDT) Received: from ?IPv6:2607:fb90:a6bc:d755:91d0:3885:2b34:35ac? ([2607:fb90:a6bc:d755:91d0:3885:2b34:35ac]) by smtp.gmail.com with ESMTPSA id v14sm14288824pfd.153.2017.11.03.09.19.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 09:19:40 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3CDC6317-DE4D-4F9C-9AF9-094FA0EDEA72 Mime-Version: 1.0 (1.0) From: Mark Friedenbach X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Fri, 3 Nov 2017 09:19:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4F2B4652-BEB4-4202-AA30-0E8D0BEBDD17@friedenbach.org> References: <052D6E20-7194-4645-B628-1B7B7FECF330@gmail.com> To: =?utf-8?Q?Hampus_Sj=C3=B6berg?= , Bitcoin Protocol Discussion X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MIME_QP_LONG_LINE,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: =?utf-8?Q?JOSE_FEMENIAS_CA=C3=91UELO?= Subject: Re: [bitcoin-dev] Simplicity proposal - Jets? 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: Fri, 03 Nov 2017 16:19:43 -0000 --Apple-Mail-3CDC6317-DE4D-4F9C-9AF9-094FA0EDEA72 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To reiterate, none of the current work focuses on Bitcoin integration, and m= any architectures are possible. However the Jets would have to be specified and agreed to upfront for costin= g reasons, and so they would be known to all validators. There would be no r= eason to include anything more then the identifying hash in any contract usi= ng the jet. > On Nov 3, 2017, at 5:59 AM, Hampus Sj=C3=B6berg via bitcoin-dev wrote: >=20 > Thank you for your answer, Russel. >=20 > When a code path takes advantage of a jet, does the Simplicity code still n= eed to be publicly available/visible in the blockchain? I imagine that for b= ig algorithms (say for example EDCA verification/SHA256 hashing etc), it wou= ld take up a lot of space in the blockchain. > Is there any way to mitigate this? >=20 > I guess in a softfork for a jet, the Simplicity code for a jet could be de= fined as "consensus", instead of needed to be provided within every script o= utput. > When the Simplicity interpretor encounters an expression that has a jet, i= t would run the C/Assembly code instead of interpreting the Simplicity code.= By formal verification we would be sure they match. >=20 > Greetings > Hampus >=20 > 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev : >> Hi Jose, >>=20 >> Jets are briefly discussed in section 3.4 of https://blockstream.com/simp= licity.pdf >>=20 >> The idea is that we can recognize some set of popular Simplicity expressi= ons, and when the Simplicity interpreter encounters one of these expressions= it can skip over the Simplicity interpreter and instead directly evaluate t= he function using specialized C or assembly code. >>=20 >> For example, when the Simplicity interpreter encounters the Simplicity ex= pression for ECDSA verification, it might directly call into libsecp rather t= han continuing the ECDSA verification using interpreted Simplicity. >>=20 >> HTH. >>=20 >>=20 >> On Nov 2, 2017 18:35, "JOSE FEMENIAS CA=C3=91UELO via bitcoin-dev" wrote: >> Hi, >>=20 >> I am trying to follow this Simplicity proposal and I am seeing all over r= eferences to =E2=80=98jets=E2=80=99, but I haven=E2=80=99t been able to find= any good reference to it. >> Can anyone give me a brief explanation and or a link pointing to this fea= ture? >> Thanks >>=20 >>> On 31 Oct 2017, at 22:01, bitcoin-dev-request@lists.linuxfoundation.org w= rote: >>>=20 >>> The plan is that discounted jets will be explicitly labeled as jets in t= he >>> commitment. If you can provide a Merkle path from the root to a node th= at >>> is an explicit jet, but that jet isn't among the finite number of known >>> discounted jets, >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-3CDC6317-DE4D-4F9C-9AF9-094FA0EDEA72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable To reiterate, none of the current work focu= ses on Bitcoin integration, and many architectures are possible.

However the Jets would have to be specified and agreed to upfront for costi= ng reasons, and so they would be known to all validators. There would be no r= eason to include anything more then the identifying hash in any contract usi= ng the jet.

On Nov 3, 2017, at 5:59 AM, Hampus Sj=C3=B6berg vi= a bitcoin-dev <b= itcoin-dev@lists.linuxfoundation.org> wrote:

Thank you for your a= nswer, Russel.

When a code path takes advantage of a jet= , does the Simplicity code still need to be publicly available/visible in t= he blockchain? I imagine that for big algorithms (say for example EDCA verif= ication/SHA256 hashing etc), it would take up a lot of space in the blockcha= in.
Is there any way to mitigate this?

I g= uess in a softfork for a jet, the Simplicity code for a jet could be defined= as "consensus", instead of needed to be provided within every script output= .
When the Simplicity interpretor encounters an expression that ha= s a jet, it would run the C/Assembly code instead of interpreting the Simpli= city code. By formal verification we would be sure they match.

Greetings
Hampus
2017-11-03 2:10 GMT+01:00 Russell O'Connor via b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= ;:
Hi Jose,
Jets are briefly discussed in se= ction 3.4 of https://blockstream.com/simplicity.pdf

The idea is that we can recognize some set of p= opular Simplicity expressions, and when the Simplicity interpreter encounter= s one of these expressions it can skip over the Simplicity interpreter and i= nstead directly evaluate the function using specialized C or assembly code.<= /div>

For example, when the Sim= plicity interpreter encounters the Simplicity expression for ECDSA verificat= ion, it might directly call into libsecp rather than continuing the ECDSA ve= rification using interpreted Simplicity.

HTH.


On Nov 2, 2017 18:35, "JOSE FEMENIAS CA=C3= =91UELO via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
Hi= ,

I am trying to follow this Simplicity proposal and I am= seeing all over references to =E2=80=98jets=E2=80=99, but I haven=E2=80=99t= been able to find any good reference to it.
Can anyone give me a b= rief explanation and or a link pointing to this feature?
Thanks

On 31 Oct 2017, a= t 22:01, bitcoin-dev-request@lists.linuxfoundation.org wrote= :

The plan is that discou= nted 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 t= hat jet isn't among the finite number of known
discounted jets,


<= /div>
_______________________________________________
bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-3CDC6317-DE4D-4F9C-9AF9-094FA0EDEA72--