* Re: [bitcoin-dev] Simplicity proposal - Jets? [not found] <mailman.5469.1509483670.27509.bitcoin-dev@lists.linuxfoundation.org> @ 2017-11-01 10:34 ` JOSE FEMENIAS CAÑUELO 2017-11-03 0:45 ` Adán Sánchez de Pedro Crespo 2017-11-03 1:10 ` Russell O'Connor 0 siblings, 2 replies; 7+ messages in thread From: JOSE FEMENIAS CAÑUELO @ 2017-11-01 10:34 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 595 bytes --] 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, [-- Attachment #2: Type: text/html, Size: 3540 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 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 1 sibling, 0 replies; 7+ messages in thread From: Adán Sánchez de Pedro Crespo @ 2017-11-03 0:45 UTC (permalink / raw) To: bitcoin-dev Hi everyone, I agree that the paper could use some more details on the rationale behind "jets". After a couple of reads, I think I can "ELI5 them": As far as I understand, jets are a smart optimization that makes complex Simplicity contracts way cheaper to compute (ideally, comparable to Script or EVM). For this purpose, jets leverage the most important element of the Simplicity Bit Machine: the frames stack. In a Simplicity program, every expression or sub-expression can be thought of as a pure function that when applied on a certain initial read frame, results in the active write frame having a different value. This happens deterministically and without any side effects. So, if the Simplicity interpreter finds some expression whose result when applied upon a certain read frame is already known (because it has already been executed or it was somehow precomputed), it doesn't need to execute such expression step-by-step once again. Instead, it just need to write the known result to the active write frame. The paper suggests that at all times the interpreter knows the result of applying many common operations on all possible combinations of inputs in the range of 8 to 256 bits. In other words, the interpreter won't need to calculate "123 + 321" or compare "456 > 654 because the results of those expressions will be already known to it. These are stupid examples, but the savings are real for hash functions internals, elliptic curve calculations or even validation of signatures. As said before, this can help making Simplicity programs lighter on CPU usage, but it has many other benefits too: + Jets can replicate the behavior of complex chunks of Simplicity code with the guarantee that they can't introduce side effects. + Interpreter-bundled jets are formally proven. The more a Simplicity program relies on jets, the more it benefits from their safety. When proving the soundness of your program, you can just ignore the jets, assume they are valid and focus on your own logic. The paper also suggests that different sets of jets could make up different single purpose dialects, just like domain-specific languages bring richer vocabulary and semantics to the bare syntax and grammar of general-purpose languages. I hope Russel or Mark can correct me if I got something totally wrong. I must admit I really like this proposal and hereby declare myself a huge fan of their work :) -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 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 1 sibling, 2 replies; 7+ messages in thread From: Russell O'Connor @ 2017-11-03 1:10 UTC (permalink / raw) To: JOSE FEMENIAS CAÑUELO, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1498 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 4279 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 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 1 sibling, 0 replies; 7+ messages in thread From: Adán Sánchez de Pedro Crespo @ 2017-11-03 8:46 UTC (permalink / raw) To: bitcoin-dev Oops. That makes much more sense than what I said. Thanks a lot for the clarification. On 03.11.2017 02:10, Russell O'Connor via bitcoin-dev wrote: > 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 > <mailto: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 >> <mailto: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 > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <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 > -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 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 2017-11-03 16:42 ` Adán Sánchez de Pedro Crespo 1 sibling, 2 replies; 7+ messages in thread From: Hampus Sjöberg @ 2017-11-03 12:59 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion Cc: JOSE FEMENIAS CAÑUELO [-- Attachment #1: Type: text/plain, Size: 2619 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 6105 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 2017-11-03 12:59 ` Hampus Sjöberg @ 2017-11-03 16:19 ` Mark Friedenbach 2017-11-03 16:42 ` Adán Sánchez de Pedro Crespo 1 sibling, 0 replies; 7+ messages in thread From: Mark Friedenbach @ 2017-11-03 16:19 UTC (permalink / raw) To: Hampus Sjöberg, Bitcoin Protocol Discussion Cc: JOSE FEMENIAS CAÑUELO [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Simplicity proposal - Jets? 2017-11-03 12:59 ` Hampus Sjöberg 2017-11-03 16:19 ` Mark Friedenbach @ 2017-11-03 16:42 ` Adán Sánchez de Pedro Crespo 1 sibling, 0 replies; 7+ messages in thread From: Adán Sánchez de Pedro Crespo @ 2017-11-03 16:42 UTC (permalink / raw) To: bitcoin-dev If I did understand it right, you don't need to publish the Simplicity code for the "jetable" expression. That's the whole point of MAST. Each Simplicity expression can be identified by its MAST root (the Merkle root of all branches in its Abstract Syntax Tree). Imagine you want to write a Simplicity script that is roughly equivalent to P2PKH. Regardless of directly writing such script or using a higher level smart contract language, you won't likely write for yourself the part in which you compute the hash of the public key. Instead, you are expected to include some external library providing hash functions or at least copy and paste such function into your code. As everyone is expected to use the same, let's say, RIPEMD160 implementation, it doesn't matter how you included such function in your program. The point is that once you build the MAST for your program, such function will be completely replaced by its MAST root---which is nothing but a hash. This way, when the Simplicity interpreter (the BitMachine) bumps into the hash, it can look for it in a predefined jets dictionary and find the binary for a precompiled, formally proven implementation of a function that is perfectly equivalent to the original Simplicity code. On 03.11.2017 13:59, Hampus Sjöberg via bitcoin-dev 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 > <mailto:bitcoin-dev@lists•linuxfoundation.org>>: > > Hi Jose, > > Jets are briefly discussed in section 3.4 of > https://blockstream.com/simplicity.pdf > <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 > <mailto: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 >> <mailto: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 > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <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 > -- Adán Sánchez de Pedro Crespo CTO, Stampery Inc. San Francisco - Madrid ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-11-03 16:42 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[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
2017-11-03 16:42 ` Adán Sánchez de Pedro Crespo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox