📅 Original date posted:2023-05-12
🗒️ Summary of this message: The implementation of a SNARK verifier on Bitcoin's base layer is a long-term option that could take years, but Simplicity could be used to experiment on the Liquid sidechain. The proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs requires a soft fork, but establishing consensus over a particular kind of opcode is difficult due to competing proof systems with different trade-offs. Simplicity offers more flexibility and allows for updating verifiers as research advances.
📝 Original message:Hi Weiji,
> Could you please expand more on how you plan to "implement a SNARK verifier on Bitcoin’s base layer"?
First, I should clarify that I see this as a long-term option, which will take years. If Simplicity gets activated, we could use it to implement a SNARK verifier on Bitcoin's base layer. But for now, we just plan to experiment with Simplicity on the Liquid sidechain when it gets activated.
> For your information, I happen to be the one proposing a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs. My proposal requires a soft fork. You may find more information from the email archive here: https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html <https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html>;
I've seen it; however, I suppose it is hard to establish consensus over some particular kind of op_snark_verify opcode because there are so many competing proof systems with different trade-offs. For example, STARKs are great for a chain state proof as they are scalable and allow for processing huge circuits; however, I would not favor STARKs for an on-chain verifier because there are other proof systems, such as Plonky2, with much smaller proof sizes.
A nice thing about SNARK verifiers is that once we have any verifier, we can use it to wrap other proofs. E.g., we could "compress" the size of a STARK by verifying it in a Plonky2 proof.
Still, Simplicity offers much more flexibility and allows to update verifiers as the research advances.
> We might be tackling similar issues and probably could benefit from each other.
Sounds good! Please join our Telegram group, if you would like to chat about SNARKs on Bitcoin https://t.me/zerosync_chat <https://t.me/zerosync_chat>;
Cheers,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230512/4ff96f5d/attachment.html>;
Robin Linus [ARCHIVE] /
npub124…xpaq3
2023-06-07 23:21:48
in reply to nevent1q…lf2r
Author Public Key
npub12478zv0dxzfgepyn9m3v8vl8sn5yy8vhxpxump6lnfw84rslr0wqwxpaq3Seen on
wss://relay.nostr.bandPublished at
2023-06-07 23:21:48Event JSON
{
"id": "4bbd4e079f33751404b64012edd4cba0373f70d1dfdd6af68653c12c390dda48",
"pubkey": "557c7131ed30928c84932ee2c3b3e784e8421d97304dcd875f9a5c7a8e1f1bdc",
"created_at": 1686180108,
"kind": 1,
"tags": [
[
"e",
"66767e626cf963389e4efc5441f57203ea359ba5b368f041b2e20961c2150d05",
"",
"root"
],
[
"e",
"c33305f5082c52a3afbdf7662b80e71971138a71612f773e0637863d628861cb",
"",
"reply"
],
[
"p",
"eb51aedd62de3ab3f1b051323f1fd8211d08774295fd17acb5434b71525bbd7c"
]
],
"content": "📅 Original date posted:2023-05-12\n🗒️ Summary of this message: The implementation of a SNARK verifier on Bitcoin's base layer is a long-term option that could take years, but Simplicity could be used to experiment on the Liquid sidechain. The proposal for a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs requires a soft fork, but establishing consensus over a particular kind of opcode is difficult due to competing proof systems with different trade-offs. Simplicity offers more flexibility and allows for updating verifiers as research advances.\n📝 Original message:Hi Weiji,\n\n\u003e Could you please expand more on how you plan to \"implement a SNARK verifier on Bitcoin’s base layer\"?\nFirst, I should clarify that I see this as a long-term option, which will take years. If Simplicity gets activated, we could use it to implement a SNARK verifier on Bitcoin's base layer. But for now, we just plan to experiment with Simplicity on the Liquid sidechain when it gets activated.\n\n\n\u003e For your information, I happen to be the one proposing a new opcode OP_ZKP to enable the Bitcoin network to verify zkp proofs. My proposal requires a soft fork. You may find more information from the email archive here: https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html \u003chttps://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg12601.html\u003e\nI've seen it; however, I suppose it is hard to establish consensus over some particular kind of op_snark_verify opcode because there are so many competing proof systems with different trade-offs. For example, STARKs are great for a chain state proof as they are scalable and allow for processing huge circuits; however, I would not favor STARKs for an on-chain verifier because there are other proof systems, such as Plonky2, with much smaller proof sizes.\n\nA nice thing about SNARK verifiers is that once we have any verifier, we can use it to wrap other proofs. E.g., we could \"compress\" the size of a STARK by verifying it in a Plonky2 proof.\nStill, Simplicity offers much more flexibility and allows to update verifiers as the research advances.\n\n\n\u003e We might be tackling similar issues and probably could benefit from each other. \n\nSounds good! Please join our Telegram group, if you would like to chat about SNARKs on Bitcoin https://t.me/zerosync_chat \u003chttps://t.me/zerosync_chat\u003e\n\n\n\nCheers,\nRobin \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230512/4ff96f5d/attachment.html\u003e",
"sig": "e0e84589b52e1e6bfffb1e78f738515fb2bd1b80049483575ac2f235f4033b5812bf733f2fe2b0256f05d95a7a9b61ff4372f572ef1dde5256af7ecc44bd84dc"
}