Published on: 2023-05-06T02:51:33+00:00
The discussion between Weiji and ZmnSCPxj revolves around the possibility of an attack on the fullnode mempool network. The attack involves flooding the network with non-aggregated transactions and confirming a single aggregated transaction with a lower feerate in cooperation with a miner. However, ZmnSCPxj argues that this attack is not feasible due to the high cost and the need for a separate, paid aggregator outside the mempool to prevent overload on the free mempool service.To prevent the attack on non-aggregated transactions, it is suggested that transactions should be made non-aggregatable with other transactions in the mempool. Aggregation should be arranged before the blockchain-level transaction hits the mempool. Signature aggregation within a single blockchain-level transaction is allowed, but not across transactions. Similarly, cross-input ZKP aggregation is acceptable, but not cross-transaction ZKP aggregation. It is recommended to disallow ZKP aggregation once a transaction could potentially hit the mempool and require paid services for aggregation outside of the unpaid, free mempool.Weiji proposes the use of ZKPs in Bitcoin transactions and suggests that specialized computing power vendors could optimize ZKP computations. Groth16 verification can be fast enough to handle thousands of OP_ZKP transactions even on a common full node. These transactions can be put into the mempool and open to aggregation by vendors. However, it is cautioned against treating these transactions with special rules as there is no guarantee that certain OP_ZKP transactions will be aggregated or recursively verified. The cost for standalone OP_ZKP transactions might be higher, incentivizing vendors to develop aggregation/recursive verification services.The discussion also addresses the issue of verification keys exceeding the maximum script element size. It is suggested to store verification keys in configurations and only use their hash in the `scriptPubKey`. Weight units for propagation of verification keys should be adjusted similarly to `scriptPubKey`s and amounts in block data. If verification keys are permanent, they should be weighted heavier than `scriptPubKey`s and amounts. If ZKP witnesses consume more resources, their weighting should be higher as well.The proposal of a new opcode, OP_ZKP, aims to enable zero-knowledge based spending authorization in Bitcoin. This would make the Bitcoin script Turing complete and enable various applications. Security concerns, system limitations, scalability, ZKP schemes, curve choices, potential uses, and ecology implications are discussed in the proposal. Proof aggregation and recursive verification are suggested for scalability, and Groth16-BN254 is proposed as an initial choice for ZKP schemes and curve choices.The potential impact of ZKPs on smart contracts, computation power vendors, and wallet applications is also explored. Service providers could work with miners to optimize transaction generation and propose bundles of transactions to be included in blocks. Challenges include maintaining off-network UTXO entries with high security and figuring out ways for smart contracts to call each other. The heavy-duty computation task of generating proof to authorize spending is addressed, suggesting that if no secret is involved, a wallet is not needed, and the ZKP proof could serve as proof of something happening or existing.Further discussion among developers and the community is required before any BIP can be requested. The article provides relevant links to support the ideas presented.
Updated on: 2023-08-02T09:21:30.577946+00:00