Date: Thu, 04 May 2023 17:13:09 +0000
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
Precedence: list

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