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
132
133
134
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id A7F2DC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2023 17:13:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 75E3984060
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2023 17:13:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 75E3984060
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=jBOy3c4V
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 smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id HyeOHApjIj_4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2023 17:13:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9515084040
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp1.osuosl.org (Postfix) with ESMTPS id 9515084040
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 May 2023 17:13:18 +0000 (UTC)
Date: Thu, 04 May 2023 17:13:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1683220394; x=1683479594;
bh=esNlHZ6hPR3pVePYI8sKLSAMK86FZt4M5FyZGIhiWKY=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=jBOy3c4Vfoh2dkv93wiQ3dSnDfE+h674PX/08ETTAtpFZTdhsOyuhuHFau8RYvx0H
C7GKaWi8majDtjzQ+KjCwvnxN5/sl/F9XmiF8flmXIBoVuLknm0PBmqXXj50Gbn3wh
AHkCGjsqrvm5nZKTsjwlYHOX1Y1WZxBuU1NWvaJgIsTZ1VSYjhlaZ7aukfUL2euZL5
X8eyZtYPwJbO0dlltbZjEtIthzIfj8tEuWAMLUCJT9wIu1Nwbcvwq1USSAzym06G4o
WSv3MtIJVRuB+IVws2/Ycvub+/ZPq8x2XlWOavdjLXAmPoD5zNO9PgIL266MvsSbT1
3xnDgiHbPcKnA==
To: Weiji Guo <weiji.g@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <O8340coA0WBuYzHgkZ6ov7Yp3aqvnGeCeFKHh9bqZdkQTS3xtjEDlW4Hjhc7UgD1XltJyYDOFzDN4JthXq1pdCrMM8cYNfVBIOvLbR8tro8=@protonmail.com>
In-Reply-To: <CA+ydi=+6oSQ2oEeuBDQs7fzWL75h4CYb3k4_SS3VbFgxJwDGiA@mail.gmail.com>
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>
<CA+ydi=+6oSQ2oEeuBDQs7fzWL75h4CYb3k4_SS3VbFgxJwDGiA@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 17:13:19 -0000
Good morning Weiji,
The issue here is that non-aggregated transaction are a potential attack ve=
ctor.
As the network is pseudonymous, an anonymous attacker can flood the fullnod=
e mempool network with large numbers of non-aggregated transactions, then i=
n cooperation with a miner confirm a single aggregated transaction with low=
er feerate than what it put in the several non-aggregated transactions.
The attacker ends up paying lower for the single confirmed transaction, eve=
n though it cost the fullnode network a significant amount of CPU to proces=
s and validate all the non-aggregated transactions.
Once the single aggregate transaction is confirmed, the fullnodes will remo=
ve the non-aggregated transactions from the mempool, clearing out their mem=
pool limit.
Then the attacker can once again flood the fullnode mempool network with mo=
re non-aggregated transactions, and again repeat with an aggregated transac=
tion that pays below the total of the non-aggregated transactions, repeated=
ly increasing the load on the mempool.
Thus, we should really make transactions that could appear in the mempool n=
on-aggregatable with other transactions in the mempool.
You should arrange for aggregation before the blockchain-level transaction =
hits the mempool.
One can compare cross-input signature aggregation designs.
Signature aggregation is only allowed within a single blockchain-level tran=
saction, not across transactions, precisely so that a transaction that appe=
ars in the mempool cannot have its signatures aggregated with other transac=
tions, and preventing the above attack.
Anyone trying to take advantage of signature aggregation needs to cooperati=
vely construct the blockchain-level transaction outside of the mempool with=
other cooperating actors, all of which perform the validation themselves b=
efore anything hits the mempool.
Similarly I can imagine that cross-input ZKP aggregation would be acceptabl=
e, but not cross-transaction ZKP aggregation.
(And if you want to push for ZKP aggregation, you should probably push for =
cross-input signature aggregation first, as you would probably need to solv=
e similar problems in detail and I imagine signature aggregation is simpler=
than general ZKP aggregation.)
Always expect that the blockchain and its supporting network is attackable.
Do ***NOT*** focus on blocks --- focus on the load on the mempool (the bloc=
k weight limit is a limit on the mempool load, not a limit on the block CPU=
load!).
The mempool is a free service, we should take care not to make it abusable.
On the other hand, blockspace is a paid service, so load on it is less impo=
rtant; it is already paid for.
I strongly recommend **DISALLOWING** aggregation of ZKPs once a transaction=
is in a form that could potentially hit the mempool, and to require paid s=
ervices for aggregation, outside of the unpaid, free mempool.
Regards,
ZmnSCPxj
|
