Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9723C002A for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion 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 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: 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