path: root/4a/30c59bbfb38226ddc23dd00bfb5c18a81148e2

Return-Path: <weiji.g@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CD123C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 May 2023 15:31:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A034460EA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 May 2023 15:31:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A034460EA5
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=Tted1i9E
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id iujHQ7BgY03w
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 May 2023 15:31:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8D52860E11
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com
 [IPv6:2607:f8b0:4864:20::a32])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8D52860E11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 May 2023 15:31:35 +0000 (UTC)
Received: by mail-vk1-xa32.google.com with SMTP id
 71dfb90a1353d-44fcbe08ae2so213081e0c.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 04 May 2023 08:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1683214294; x=1685806294;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=DRNvagUrozFChvvDPxnnhwjlJR9Z+W76koL5Mm1dokg=;
 b=Tted1i9Ef0+6HIyNGg8A6cNxdwhgBdNZcT5bdvVtjvywIJ8cdeILRmfnPQNDd73CCR
 /0HRSKxg0XaynVKSHexo5xw/8azPJp5jrZ6qTVNt14F46/+7VzE7FcfpsD+jBAFVws+K
 0naBchTF9K6rLPj2XYzaVQcRoQsUKsfXoWU2VXkXZcjXIpFUuuCLgrTHZsVAsTnuKbmr
 2u+rFPSCHuKSMgC3GJRmh6+MoKpTCOhqI9FoA7SI3emZu1mYEYSniQkb+5fAKOygJNaU
 lJzRtNd7/PTiOH7og1tJNSM/3W28JcB5fZD2zfbswotpXeikYD5/4CUBdYGYVzxb/K0l
 YNmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683214294; x=1685806294;
 h=cc: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=DRNvagUrozFChvvDPxnnhwjlJR9Z+W76koL5Mm1dokg=;
 b=Ngi2s8Py2tKYnR1vgGEtVm8OqAtRuS0DevCAv7wI+thmR0gXNZCYkBdRlThHbvJsV2
 uxK7Bi+scPixa+F0HtZtnYofltrvo+ixTPOLSmtYC1iIlbvhAlPUSEAb024kUewazNoQ
 vlecBFXGoaSbdL5V5FheHU7Qwa0tfIWdDykIe3f+wKCFboatgd3nHXObIzjvEz+UymZy
 PhNlrV8hxEFiCNmGTOVacl+Wp0ajJ5PipOHEZqGEaknHiaeErWss8YQJ2FKKTP3y1gaH
 UNIuPeF3zKAeLCpmG6HJyRVN0I3c0HbfWB3mMV/fQIV36G5uH0R5M9c76zVAcddwJYEs
 EZww==
X-Gm-Message-State: AC+VfDzEPk8e+vYarqkxvAWUU6n372Nw2jSJyMYKSjT1NWQ8Wj5QYwbZ
 Y8PqqwmZBcdo+audKSBRFi2o3mV8XRJzQu7avZkdbTvGrWk=
X-Google-Smtp-Source: ACHHUZ60+IBtYJt8ibxNRlg4KZLHuei4i/uJlkMPbsbHA8O9lFshsa+1ocDunjhKMY+Y5Wra+ABQo3msDTtraBF0j9I=
X-Received: by 2002:a1f:bf4d:0:b0:44f:f77f:f37 with SMTP id
 p74-20020a1fbf4d000000b0044ff77f0f37mr122163vkf.11.1683214294169; Thu, 04 May
 2023 08:31:34 -0700 (PDT)
MIME-Version: 1.0
References: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
 <xNzSDtvj-BH4EW9eJMqn_yAiVUEiggnS3WIrvLml6gGAZ6CPADO9pbPV4B30txzSY9laEmX3ckXX8L2Hu18ZrWMUjMH23csL-YK-mDse6DY=@protonmail.com>
 <CA+ydi=K7kePFPXbTP6S63SdddORnc6nVoHqR4gDVoeX3uY-S-Q@mail.gmail.com>
 <s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com>
In-Reply-To: <s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com>
From: Weiji Guo <weiji.g@gmail.com>
Date: Thu, 4 May 2023 23:31:22 +0800
Message-ID: <CA+ydi=+6oSQ2oEeuBDQs7fzWL75h4CYb3k4_SS3VbFgxJwDGiA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000015bc2b05fadfdefd"
X-Mailman-Approved-At: Thu, 04 May 2023 15:47:35 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based
 spending authorization
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: Thu, 04 May 2023 15:31:36 -0000

--00000000000015bc2b05fadfdefd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

I do mean to have specialized computing power vendors, which could happen
to be miners, or not. Optiming ZKP computations is rather different from
Bitcoin mining so I expect those vendors to be from more research-driven
teams focused in cryptographic engineering.

I am open to whether to put those transactions in mempool or not. I
apologize for giving an inaccurate number earlier about the verification
cost. I just ran gnark-bench on my Mac M2, it turns out the cost for
Groth16 verification could be as fast as 1ms. For Plonk it is around 1.6ms.
So it seems even a common fullnode could handle thousands of OP_ZKP
transactions. In that case, the ZKP transactions could be put into mempool,
and be open to be aggregated by some vendor. Fullnodes should verify these
transactions as well. It does not seem a good idea to treat them with
special rules as there is no guarantee that certain OP_ZKP transactions
will be aggregated or recursively verified. Of course, the weighting should
be well benchmarked and calculated. The cost for those *standalone* OP_ZKP
transactions might be higher due to more data and/or higher weighting. This
incentivizes vendors to develop aggregation / recursive verification
services to drive down the fee requirements and profit from doing so (fee
extraction). I also expect to see an open market where various vendors can
compete against each other, so it makes sense to have these transactions
openly visible to all participants.

Meanwhile, some transactions are meant to be off-chain. For example, a
would-be smart contract can aggregate many related transactions in a OP_ZKP
transaction. Those aggregated transactions should *not* be transmitted
within the Bitcoin network. They could even be *not* valid Bitcoin
transactions. Usually the smart contract operator or its community could
host such a service.

Consider a potential situation in a few years: there are thousands of
active smart contracts based on OP_ZKP, and each block contains a few
hundred OP_ZKP transactions, each one of them aggregates / recursively
verifies many transactions. The effective TPS of the Bitcoin network could
far exceed the current value, reaching the range of thousands or even more.

Hope this clarifies.
Weiji

On Tue, May 2, 2023 at 11:01=E2=80=AFPM ZmnSCPxj <ZmnSCPxj@protonmail.com> =
wrote:

>
> Good morning Weiji,
>
> > Meanwhile, as we can potentially aggregate many proofs or recursively
> verify even more, the average cost might still be manageable.
>
> Are miners supposed to do this aggregation?
>
> If miners do this aggregation, then that implies that all fullnodes must
> also perform the **non**-aggregated validation as transactions flow from
> transaction creators to miners, and that is the cost (viz. the
> **non**-aggregated cost) that must be reflected in the weight.
> We should note that fullnodes are really miners with 0 hashpower, and any
> cost you impose on miners is a cost you impose on all fullnodes.
>
> If you want to aggregate, you might want to do that in a separate network
> that does ***not*** involve Bitcoin fullnodes, and possibly allow for som=
e
> kind of extraction of fees to do aggregation, then have already-aggregate=
d
> transactions in the Bitcoin mempool, so that fullnodes only need validate
> already-aggregated transactions.
>
> Remember, validation is run when a transaction enters the mempool, and is
> **not** re-run when an in-mempool transaction is seen in a block
> (`blocksonly` of course does not follow this as it has no mempool, but mo=
st
> fullnodes are not `blocksonly`).
> If you intend to aggregate transactions in the mempool, then at the worst
> case a fullnode will be validating every non-aggregated transaction, and
> that is what we want to limit by increasing the weight of heavy-validatio=
n
> transactions.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>I do mean to have speciali=
zed computing power vendors, which could happen to be miners, or not. Optim=
ing ZKP computations is rather different from Bitcoin mining so I expect th=
ose vendors to be from more research-driven teams focused in cryptographic =
engineering.=C2=A0</div><div><br></div><div>I am open to whether to put tho=
se transactions in mempool or not. I apologize for giving an inaccurate num=
ber earlier about the verification cost. I just ran gnark-bench on my Mac M=
2, it turns out the cost for Groth16 verification could be as fast as 1ms. =
For Plonk it is around 1.6ms. So it seems even a common fullnode could hand=
le thousands of OP_ZKP transactions. In that case, the ZKP transactions cou=
ld be put into mempool, and be open to be aggregated by some vendor. Fullno=
des should verify these transactions as well. It does not seem a good idea =
to treat them with special rules as there is no guarantee that certain OP_Z=
KP transactions will be aggregated or recursively verified. Of course, the =
weighting should be well benchmarked and calculated. The cost for those *st=
andalone* OP_ZKP transactions might be higher due to more data and/or highe=
r weighting. This incentivizes vendors to develop aggregation / recursive v=
erification services to drive down the fee requirements and profit from doi=
ng so (fee extraction). I also expect to see an open market where various v=
endors can compete against each other, so it makes sense to have these tran=
sactions openly visible to all participants.=C2=A0</div><div><br></div><div=
>Meanwhile, some transactions are meant to be off-chain. For example, a wou=
ld-be smart contract can aggregate many related transactions in a OP_ZKP tr=
ansaction. Those aggregated transactions should *not* be transmitted within=
 the Bitcoin network. They could even be *not* valid Bitcoin transactions. =
Usually the smart contract operator or its community could host such a serv=
ice.=C2=A0</div><div><br></div><div>Consider a potential situation in a few=
 years: there are thousands of active smart contracts based on OP_ZKP, and =
each block contains a few hundred OP_ZKP transactions, each one of them agg=
regates / recursively verifies many transactions. The effective TPS of the =
Bitcoin network could far exceed the current value, reaching the range of t=
housands or even more.</div><div><br></div><div>Hope this clarifies.</div><=
div>Weiji</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Tue, May 2, 2023 at 11:01=E2=80=AFPM ZmnSCPxj &lt;<a hre=
f=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Good morning Weiji,<br>
<br>
&gt; Meanwhile, as we can potentially aggregate many proofs or recursively =
verify even more, the average cost might still be manageable.<br>
<br>
Are miners supposed to do this aggregation?<br>
<br>
If miners do this aggregation, then that implies that all fullnodes must al=
so perform the **non**-aggregated validation as transactions flow from tran=
saction creators to miners, and that is the cost (viz. the **non**-aggregat=
ed cost) that must be reflected in the weight.<br>
We should note that fullnodes are really miners with 0 hashpower, and any c=
ost you impose on miners is a cost you impose on all fullnodes.<br>
<br>
If you want to aggregate, you might want to do that in a separate network t=
hat does ***not*** involve Bitcoin fullnodes, and possibly allow for some k=
ind of extraction of fees to do aggregation, then have already-aggregated t=
ransactions in the Bitcoin mempool, so that fullnodes only need validate al=
ready-aggregated transactions.<br>
<br>
Remember, validation is run when a transaction enters the mempool, and is *=
*not** re-run when an in-mempool transaction is seen in a block (`blocksonl=
y` of course does not follow this as it has no mempool, but most fullnodes =
are not `blocksonly`).<br>
If you intend to aggregate transactions in the mempool, then at the worst c=
ase a fullnode will be validating every non-aggregated transaction, and tha=
t is what we want to limit by increasing the weight of heavy-validation tra=
nsactions.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000015bc2b05fadfdefd--