1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B9723C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Apr 2023 02:16:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 8DA8260BDB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Apr 2023 02:16:07 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8DA8260BDB
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=ACxtYgRF
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-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 GZNOHWWRej4i
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Apr 2023 02:16:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D6C9360ACA
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp3.osuosl.org (Postfix) with ESMTPS id D6C9360ACA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Apr 2023 02:16:02 +0000 (UTC)
Date: Sun, 30 Apr 2023 02:15:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1682820959; x=1683080159;
bh=bMOd4SgeJx+1P35OyAe+DkRT+opElOP6ue9nARhjM30=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=ACxtYgRF/5VJxdzpfWvZTZtZL/qQvnIq3jFW75A1CTm4aTuWuzsPfQn5j2lK+w8MC
hdy7b1tGfMXJZmExgB1uPdLCHw/zPCjTYuM5RmgQfcaLXagchAZbb8/rl3wIly24aY
6sMSlNj5dsoC8H9u8/0Lb+uIG3f9EVg14pHVZMDz0a6RzdXkMKRNT91um3Z/eMWVB8
8FBCUxD/1qxNrgKSVJ6tJJr69ds80fsGLEGQMaa9VYk0fho49rOXL9IZzbw/zqdYy0
iGkyjoRzE0xjpZBQQ82OsBZMyXhpJkHTDjRrR7UmmMxtRDK+RQPEQLopg1DcXSCPV/
4/leADs6xIG3w==
To: Weiji Guo <weiji.g@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xNzSDtvj-BH4EW9eJMqn_yAiVUEiggnS3WIrvLml6gGAZ6CPADO9pbPV4B30txzSY9laEmX3ckXX8L2Hu18ZrWMUjMH23csL-YK-mDse6DY=@protonmail.com>
In-Reply-To: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
References: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Sun, 30 Apr 2023 02:16:07 -0000
Good morning Weiji,
Have not completed reading, but this jumped out to me:
> 3. Dealing with system limitation: verification keys could be very long =
and exceed the MAX_SCRIPT_ELEMENT_SIZE (520 bytes). They could be put into =
configurations and only use their hash in the scriptPubKey. The configurati=
on information such as new verification keys could be propagated through P2=
P messages (we might need a separate BIP for this);
`scriptPubKey` is consensus-critical, and these new P2P messages would have=
to be consensus-critical.
As all nodes need to learn the new verification keys, we should consider ho=
w much resources are spent on each node just to maintain and forever rememb=
er verification keys.
Currently our resource-tracking methodology is via the synthetic "weight un=
its" computation.
This reflects resources spent on acquiring block data, as well as maintaini=
ng the UTXO database.
For instance, the "witness discount" where witness data (i.e. modern equiva=
lent of `scriptSig`) is charged 1/4 the weight units of other data, exists =
because spending a UTXO reduces the resources spent in the UTXO database, a=
lthough still consumes resources in downloading block data (hence only a di=
scount, not free or negative/rebate).
Similarly, any propagation of verification keys would need a similar adjust=
ment for weight units.
As verification keys MUST be seen by all nodes before they can validate an =
`OP_ZKP`, I would suggest that it is best included in block data (which sim=
ilarly needs to be seen by all nodes), together with some weight unit adjus=
tment for that data, depending on how much resources verification keys woul=
d consume.
This is similar to how `scriptPubKey`s and amounts are included in block da=
ta, as those data are kept in the UTXO database, which nodes must maintain =
in order to validate the blockchain.
If verification keys are permanent, they should probably be weighted heavie=
r than `scriptPubKey`s and amounts --- UTXOs can theoretically be deleted l=
ater by spending the UTXO (which reduces UTXO database size), while any dat=
a that must be permanently stored in a database must correspondingly be wei=
ghted higher.
Similarly, my understanding is that the CPU resources needed by validation =
of generic ZKPs is higher than that required for validation of ECC signatur=
es.
Much of the current weight calculation assumes that witness data is primari=
ly ECC signatures, so if ZKP witnesses translate to higher resource consump=
tion, the weighting of ZKP witnesses should also be higher (i.e. greater th=
an the 1/4 witness-discounted weight of current witness data).
Regards,
ZmnSCPxj
|
