From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Weiji Guo <weiji.g@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization
Date: Thu, 04 May 2023 17:13:09 +0000 [thread overview]
Message-ID: <O8340coA0WBuYzHgkZ6ov7Yp3aqvnGeCeFKHh9bqZdkQTS3xtjEDlW4Hjhc7UgD1XltJyYDOFzDN4JthXq1pdCrMM8cYNfVBIOvLbR8tro8=@protonmail.com> (raw)
In-Reply-To: <CA+ydi=+6oSQ2oEeuBDQs7fzWL75h4CYb3k4_SS3VbFgxJwDGiA@mail.gmail.com>
Good morning Weiji,
The issue here is that non-aggregated transaction are a potential attack vector.
As the network is pseudonymous, an anonymous attacker can flood the fullnode mempool network with large numbers of non-aggregated transactions, then in cooperation with a miner confirm a single aggregated transaction with lower feerate than what it put in the several non-aggregated transactions.
The attacker ends up paying lower for the single confirmed transaction, even though it cost the fullnode network a significant amount of CPU to process and validate all the non-aggregated transactions.
Once the single aggregate transaction is confirmed, the fullnodes will remove the non-aggregated transactions from the mempool, clearing out their mempool limit.
Then the attacker can once again flood the fullnode mempool network with more non-aggregated transactions, and again repeat with an aggregated transaction that pays below the total of the non-aggregated transactions, repeatedly increasing the load on the mempool.
Thus, we should really make transactions that could appear in the mempool non-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 transaction, not across transactions, precisely so that a transaction that appears in the mempool cannot have its signatures aggregated with other transactions, and preventing the above attack.
Anyone trying to take advantage of signature aggregation needs to cooperatively construct the blockchain-level transaction outside of the mempool with other cooperating actors, all of which perform the validation themselves before anything hits the mempool.
Similarly I can imagine that cross-input ZKP aggregation would be acceptable, 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 solve 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 block 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 important; 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 services for aggregation, outside of the unpaid, free mempool.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2023-05-04 17:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 8:29 Weiji Guo
2023-04-30 2:15 ` ZmnSCPxj
2023-05-01 12:46 ` Weiji Guo
2023-05-02 15:01 ` ZmnSCPxj
2023-05-04 15:31 ` Weiji Guo
2023-05-04 17:13 ` ZmnSCPxj [this message]
2023-05-05 23:06 ` Weiji Guo
2023-05-06 2:51 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='O8340coA0WBuYzHgkZ6ov7Yp3aqvnGeCeFKHh9bqZdkQTS3xtjEDlW4Hjhc7UgD1XltJyYDOFzDN4JthXq1pdCrMM8cYNfVBIOvLbR8tro8=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=weiji.g@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox