public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: "JOSE FEMENIAS CAÑUELO" <jose.femenias@gmail.com>
Subject: Re: [bitcoin-dev] Simplicity proposal - Jets?
Date: Fri, 3 Nov 2017 09:19:39 -0700	[thread overview]
Message-ID: <4F2B4652-BEB4-4202-AA30-0E8D0BEBDD17@friedenbach.org> (raw)
In-Reply-To: <CAFMkqK_rXb9fAiGC_qNf5nj_cShJgAB4qTUsCM+R07DSAau2TA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]

To reiterate, none of the current work focuses on Bitcoin integration, and many architectures are possible.

However the Jets would have to be specified and agreed to upfront for costing reasons, and so they would be known to all validators. There would be no reason to include anything more then the identifying hash in any contract using the jet.

> On Nov 3, 2017, at 5:59 AM, Hampus Sjöberg via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Thank you for your answer, Russel.
> 
> When a code path takes advantage of a jet, does the Simplicity code still need to be publicly available/visible in the blockchain? I imagine that for big algorithms (say for example EDCA verification/SHA256 hashing etc), it would take up a lot of space in the blockchain.
> Is there any way to mitigate this?
> 
> I guess 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 has a jet, it would run the C/Assembly code instead of interpreting the Simplicity code. By formal verification we would be sure they match.
> 
> Greetings
> Hampus
> 
> 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
>> Hi Jose,
>> 
>> Jets are briefly discussed in section 3.4 of https://blockstream.com/simplicity.pdf
>> 
>> The idea is that we can recognize some set of popular Simplicity expressions, and when the Simplicity interpreter encounters one of these expressions it can skip over the Simplicity interpreter and instead directly evaluate the function using specialized C or assembly code.
>> 
>> For example, when the Simplicity interpreter encounters the Simplicity expression for ECDSA verification, it might directly call into libsecp rather than continuing the ECDSA verification using interpreted Simplicity.
>> 
>> HTH.
>> 
>> 
>> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Hi,
>> 
>> I am trying to follow this Simplicity proposal and I am seeing all over references to ‘jets’, but I haven’t been able to find any good reference to it.
>> Can anyone give me a brief explanation and or a link pointing to this feature?
>> Thanks
>> 
>>> On 31 Oct 2017, at 22:01, bitcoin-dev-request@lists.linuxfoundation.org wrote:
>>> 
>>> 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,
>> 
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 7227 bytes --]

  reply	other threads:[~2017-11-03 16:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.5469.1509483670.27509.bitcoin-dev@lists.linuxfoundation.org>
2017-11-01 10:34 ` [bitcoin-dev] Simplicity proposal - Jets? JOSE FEMENIAS CAÑUELO
2017-11-03  0:45   ` Adán Sánchez de Pedro Crespo
2017-11-03  1:10   ` Russell O'Connor
2017-11-03  8:46     ` Adán Sánchez de Pedro Crespo
2017-11-03 12:59     ` Hampus Sjöberg
2017-11-03 16:19       ` Mark Friedenbach [this message]
2017-11-03 16:42       ` Adán Sánchez de Pedro Crespo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2B4652-BEB4-4202-AA30-0E8D0BEBDD17@friedenbach.org \
    --to=mark@friedenbach.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=hampus.sjoberg@gmail.com \
    --cc=jose.femenias@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox