path: root/ad/8ad4a3c71454d595cc16c36c0627a0882eadc3

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BB8C7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 20:29:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 82530418DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 20:29:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 82530418DC
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com
 header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=VfPqr+2u
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id I94OwcRLwpvu
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 20:29:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E946F418B9
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [IPv6:2607:f8b0:4864:20::1029])
 by smtp4.osuosl.org (Postfix) with ESMTPS id E946F418B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 20:29:38 +0000 (UTC)
Received: by mail-pj1-x1029.google.com with SMTP id
 u8-20020a17090a5e4800b002106dcdd4a0so9259371pji.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 04 Nov 2022 13:29:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=j950vh7Tf5XbSf0+v4qLpIVt959s5NdV4N50yYp8w4s=;
 b=VfPqr+2uj9h8oKm6Hjrx+lcpfQLz+3C4HlEtULMh7iM/bk3yKKxUGfrg4WaYegH4Lb
 mBy/hQzuGkVYn1xnOQQ6jYYvSLNwVMGoT0MPcSg2Jq+by/OmGOht42TgA35MnUr5QBtr
 yE3JX3YRQTEj6C0mT5PMm6cOvlYBcStxC9C7OLxKLATLfthJ/XfexpZnrQfvyFy0xr4u
 n+9ZC1fVotdX3pqhvUbqn/uZdCeQFu21VV4qVQQ9qv4oJ1BaRHeZGMfiIjm9vu4Zx+wY
 LZaX7iNdMBKQyb4JOBOHs0FZS2p1eremGCTRyYkKnzzApwkA/5Kp/GLNYVj84F7aMxPG
 8rHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=j950vh7Tf5XbSf0+v4qLpIVt959s5NdV4N50yYp8w4s=;
 b=CCJG2XV6XAd7SrtT6zrM4qCv+fJbPUbOtqIWCheMAqzz1Usf0PlJguY4TatkgVtrLX
 85yRbRh0SJKS4xbX/lVyVCcTAqWdv5c+v6BcbmNU87fvdiv0iy0XEqFsxkq83He9LRD4
 GOgkS/LTkLMf2MROjf45nBfScFBptHDPT3dCAj2ycNgEQR5fWhvp8Vn1BZ4HtRfe6sCi
 cwlDkBsTlNrUWHb31z3Jq2hQK89bmJNMjdrSkram0ApKQ6xcgtGUiCgrRTZylr+hU72i
 J1PgWpN+2xQL6PPu3r7/Te1lT65oXk16H/LD2Mj6WX54FL/e2RShk8gfKh4qnovlrAZh
 LGWw==
X-Gm-Message-State: ACrzQf1xza53mTxFQOeqdeD1eBFWQ/d9PExaETSaT13dPHYlGI7J/lYq
 ZGiW2wvEdoLym6RI7QWpMoPrK8vqDkD5nUuB6l2KXA==
X-Google-Smtp-Source: AMsMyM5LCLSd8+NnmXXqgUA67Mf3r9PcFs3wPMKRqrurE0Miv9t/SKCTzJBuAqHgRK/4ceiDA35OpVTCmiGR35T9dGM=
X-Received: by 2002:a17:902:f2cb:b0:187:2cf0:71b7 with SMTP id
 h11-20020a170902f2cb00b001872cf071b7mr24494133plc.159.1667593778240; Fri, 04
 Nov 2022 13:29:38 -0700 (PDT)
MIME-Version: 1.0
References: <689ed481-e7eb-4fea-8ca7-578503f3f285@app.fastmail.com>
 <CAB3F3Dt5oy93duGvYb7SZ7wn7DCvn9FjVwRU9ENNa79yjzmdCQ@mail.gmail.com>
 <224cf2f4-2577-4331-9977-ea71e9723ffe@app.fastmail.com>
 <WJ0jiInq_I_IiiT8EiAZZN6axo2pSIRCxQWfyvgU-4rjRmeHnCXFNGWFSXoeOv7nVmqoAPr6EHeXRgc-1DfiPX3C8xHwdYzs2qn4Lck06fs=@protonmail.com>
 <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
In-Reply-To: <629da3d8-ee34-9acb-511b-4af1913eceff@protonmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 4 Nov 2022 16:29:26 -0400
Message-ID: <CAMZUoK=O967fgNkmbEcLAJ6N54GuT7vwAAP5FFvKLoYtoD4=2A@mail.gmail.com>
To: Trey Del Bonis <trey.delbonis@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c83c2705ecaaee7e"
Subject: Re: [bitcoin-dev] Validity Rollups on Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2022 20:29:40 -0000

--000000000000c83c2705ecaaee7e
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Instead of that approach, I assume we have fairly granular transaction
> introspection opcodes from a list in Elements [2] (which seem like they
> aren't actually used in mainnet Liquid?)


These opcodes went live on Liquid along with Taproot <
https://blog.liquid.net/taproot-on-liquid-is-now-live/>, so feel free to
try them out on Elements or Liquid.

One complicated part is the actual proof verification.  I had considered
> looking into what it would take to build a verifying for a modern proof
> system if we used pairings as a primitive, but it turns out even that is
> pretty involved even in a higher level language (at least for PLONK [3])
> and would be error-prone when trying to adapt the code for new circuits
> with differently-shaped public inputs.  The size of the code on-chain
> alone would probably make it prohibitively expensive, so it would be a
> lot more efficient just to assume we can introduce a specific opcode for
> doing a proof verification implemented natively.  The way I assumed it
> would work is taking the serialized proof, a verification key, and the
> public input as separate stack items.  The public input is the
> concatenation of the state and deposit commitments we took from the
> input, the batch post-state commitment (provided as part of the
> witness), data from transaction outputs corresponding to
> internally-initiated withdrawals from the rollup, and the rollup batch
> data itself (also passed as part of the witness).
>

I'd be interested in knowing what sort of Simplicity Jets would facilitate
rollups.  I suppose some pairing-friendly curve operations would do.  It
might not make the first cut of Simplicity, but we will see.

Simplicity's design doesn't have anything like a 520 byte stack limit.
There is just going to be an overall maximum allowed Simplicity evaluation
state size of some value that I have yet to decide.  I would imagine it to
be something like 1MB.

--000000000000c83c2705ecaaee7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Nov 4, 2022 at 4:04 PM Trey Del Bonis via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><br>
Instead of that approach, I assume we have fairly granular transaction<br>
introspection opcodes from a list in Elements [2] (which seem like they<br>
aren&#39;t actually used in mainnet Liquid?)</blockquote></div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">These opcodes went li=
ve on Liquid along with Taproot &lt;<a href=3D"https://blog.liquid.net/tapr=
oot-on-liquid-is-now-live/">https://blog.liquid.net/taproot-on-liquid-is-no=
w-live/</a>&gt;, so feel free to try them out on Elements or Liquid.<br></d=
iv><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
One complicated part is the actual proof verification.=C2=A0 I had consider=
ed<br>
looking into what it would take to build a verifying for a modern proof<br>
system if we used pairings as a primitive, but it turns out even that is<br=
>
pretty involved even in a higher level language (at least for PLONK [3])<br=
>
and would be error-prone when trying to adapt the code for new circuits<br>
with differently-shaped public inputs.=C2=A0 The size of the code on-chain<=
br>
alone would probably make it prohibitively expensive, so it would be a<br>
lot more efficient just to assume we can introduce a specific opcode for<br=
>
doing a proof verification implemented natively.=C2=A0 The way I assumed it=
<br>
would work is taking the serialized proof, a verification key, and the<br>
public input as separate stack items.=C2=A0 The public input is the<br>
concatenation of the state and deposit commitments we took from the<br>
input, the batch post-state commitment (provided as part of the<br>
witness), data from transaction outputs corresponding to<br>
internally-initiated withdrawals from the rollup, and the rollup batch<br>
data itself (also passed as part of the witness).<br></blockquote><div><br>=
</div><div>I&#39;d be interested in knowing what sort of Simplicity Jets wo=
uld facilitate rollups.=C2=A0 I suppose some pairing-friendly curve operati=
ons would do.=C2=A0 It might not make the first cut of Simplicity, but we w=
ill see.</div><div><br></div><div>Simplicity&#39;s design doesn&#39;t have =
anything like a 520 byte stack limit.=C2=A0 There is just going to be an ov=
erall maximum allowed Simplicity evaluation state size of some value that I=
 have yet to decide.=C2=A0 I would imagine it to be something like 1MB.<br>=
</div></div></div>

--000000000000c83c2705ecaaee7e--