📅 Original date posted:2017-11-03
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171103/cffee143/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 18:07:29
in reply to nevent1q…4tlu
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:07:29Event JSON
{
"id": "448056b22ca96b0482e39c1a787453b016eb5d67dc9dbcbc63e9b113def84799",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686161249,
"kind": 1,
"tags": [
[
"e",
"f66293ea7a9b32888732d42282e8e2d2c8c37fd29a8c31abaf65ab4ee416ee28",
"",
"root"
],
[
"e",
"672872dd41b020a1a2a4198dfb5fb074dd199537db3a5571be1220b79d80e02e",
"",
"reply"
],
[
"p",
"7f05c6d469aea3aebb69433a3de1336e36d9b0e34b54488cca80118b30a2e0ea"
]
],
"content": "📅 Original date posted:2017-11-03\n📝 Original message:To reiterate, none of the current work focuses on Bitcoin integration, and many architectures are possible.\n\nHowever 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.\n\n\u003e On Nov 3, 2017, at 5:59 AM, Hampus Sjöberg via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Thank you for your answer, Russel.\n\u003e \n\u003e 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.\n\u003e Is there any way to mitigate this?\n\u003e \n\u003e 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.\n\u003e 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.\n\u003e \n\u003e Greetings\n\u003e Hampus\n\u003e \n\u003e 2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\u003e Hi Jose,\n\u003e\u003e \n\u003e\u003e Jets are briefly discussed in section 3.4 of https://blockstream.com/simplicity.pdf\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e HTH.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On Nov 2, 2017 18:35, \"JOSE FEMENIAS CAÑUELO via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Hi,\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e Can anyone give me a brief explanation and or a link pointing to this feature?\n\u003e\u003e Thanks\n\u003e\u003e \n\u003e\u003e\u003e On 31 Oct 2017, at 22:01, bitcoin-dev-request at lists.linuxfoundation.org wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e The plan is that discounted jets will be explicitly labeled as jets in the\n\u003e\u003e\u003e commitment. If you can provide a Merkle path from the root to a node that\n\u003e\u003e\u003e is an explicit jet, but that jet isn't among the finite number of known\n\u003e\u003e\u003e discounted jets,\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171103/cffee143/attachment.html\u003e",
"sig": "fcbd0a82f7360f2f8939d2933f48106044cb85aee5f5cc45a61e6ad9defbfa2ccb531797ae93bacb998cb37b25dfe7af993f70ad7af4b752ba76272dc508eb82"
}