Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A7F2DC002A for ; 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 ; 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 ; 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 ; 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 From: ZmnSCPxj Message-ID: In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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