📅 Original date posted:2017-11-03
📝 Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto: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
>> <mailto: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
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Adán Sánchez de Pedro Crespo
CTO, Stampery Inc.
San Francisco - Madrid
Adán Sánchez de Pedro Crespo [ARCHIVE] /
npub1gt…khzxn
2023-06-07 18:07:30
in reply to nevent1q…ayr0
Author Public Key
npub1gtysrlxd5svywueh4767hrj3wfnx2gcx2wdtnnkhr9k57drhh52q3khzxnPublished at
2023-06-07 18:07:30Event JSON
{
"id": "8bdc75ca6b2a451229db662f8e75bb75f36c14c22e552ee6a995289ab9e056d2",
"pubkey": "42c901fccda418477337afb5eb8e517266652306539ab9ced7196d4f3477bd14",
"created_at": 1686161250,
"kind": 1,
"tags": [
[
"e",
"f66293ea7a9b32888732d42282e8e2d2c8c37fd29a8c31abaf65ab4ee416ee28",
"",
"root"
],
[
"e",
"448056b22ca96b0482e39c1a787453b016eb5d67dc9dbcbc63e9b113def84799",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2017-11-03\n📝 Original message:If I did understand it right, you don't need to publish the Simplicity\ncode for the \"jetable\" expression.\n\nThat's the whole point of MAST. Each Simplicity expression can be\nidentified by its MAST root (the Merkle root of all branches in its\nAbstract Syntax Tree).\n\nImagine you want to write a Simplicity script that is roughly equivalent\nto P2PKH. Regardless of directly writing such script or using a higher\nlevel smart contract language, you won't likely write for yourself the\npart in which you compute the hash of the public key. Instead, you are\nexpected to include some external library providing hash functions or at\nleast copy and paste such function into your code.\n\nAs everyone is expected to use the same, let's say, RIPEMD160\nimplementation, it doesn't matter how you included such function in your\nprogram. The point is that once you build the MAST for your program,\nsuch function will be completely replaced by its MAST root---which is\nnothing but a hash.\n\nThis way, when the Simplicity interpreter (the BitMachine) bumps into\nthe hash, it can look for it in a predefined jets dictionary and find\nthe binary for a precompiled, formally proven implementation of a\nfunction that is perfectly equivalent to the original Simplicity code.\n\n\nOn 03.11.2017 13:59, Hampus Sjöberg via bitcoin-dev wrote:\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\n\u003e still need to be publicly available/visible in the blockchain? I imagine\n\u003e that for big algorithms (say for example EDCA verification/SHA256\n\u003e 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\n\u003e defined as \"consensus\", instead of needed to be provided within every\n\u003e script output.\n\u003e When the Simplicity interpretor encounters an expression that has a jet,\n\u003e it would run the C/Assembly code instead of interpreting the Simplicity\n\u003e 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\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e:\n\u003e \n\u003e Hi Jose,\n\u003e \n\u003e Jets are briefly discussed in section 3.4 of\n\u003e https://blockstream.com/simplicity.pdf\n\u003e \u003chttps://blockstream.com/simplicity.pdf\u003e\n\u003e \n\u003e The idea is that we can recognize some set of popular Simplicity\n\u003e expressions, and when the Simplicity interpreter encounters one of\n\u003e these expressions it can skip over the Simplicity interpreter and\n\u003e instead directly evaluate the function using specialized C or\n\u003e assembly code.\n\u003e \n\u003e For example, when the Simplicity interpreter encounters the\n\u003e Simplicity expression for ECDSA verification, it might directly call\n\u003e into libsecp rather than continuing the ECDSA verification using\n\u003e interpreted Simplicity.\n\u003e \n\u003e HTH.\n\u003e \n\u003e \n\u003e On Nov 2, 2017 18:35, \"JOSE FEMENIAS CAÑUELO via bitcoin-dev\"\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Hi,\n\u003e \n\u003e I am trying to follow this Simplicity proposal and I am seeing\n\u003e all over references to ‘jets’, but I haven’t been able to find\n\u003e any good reference to it.\n\u003e Can anyone give me a brief explanation and or a link pointing to\n\u003e this feature?\n\u003e Thanks\n\u003e \n\u003e\u003e On 31 Oct 2017, at 22:01,\n\u003e\u003e bitcoin-dev-request at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev-request at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e The plan is that discounted jets will be explicitly labeled as\n\u003e\u003e jets in the\n\u003e\u003e commitment. If you can provide a Merkle path from the root to\n\u003e\u003e a node that\n\u003e\u003e is an explicit jet, but that jet isn't among the finite number\n\u003e\u003e of known\n\u003e\u003e discounted jets,\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\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\u003e \n\n-- \nAdán Sánchez de Pedro Crespo\nCTO, Stampery Inc.\nSan Francisco - Madrid",
"sig": "f8f596bfa3720ecfb51c64faaa6119f2a346eb07b57a29ae9f839475f2be05b180217b479dc87cac9b76586ab79da3b6a9fd3ffd94c835ab1d5d2bc745580cc0"
}