Subject: Re: [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization

From: ZmnSCPxj <[email-masked]>
Date: Tue, 02 May 2023 15:01:01 +0000

Good morning Weiji,

> Meanwhile, as we can potentially aggregate many proofs or recursively verify even more, the average cost might still be manageable.

Are miners supposed to do this aggregation?

If miners do this aggregation, then that implies that all fullnodes must also perform the **non**-aggregated validation as transactions flow from transaction creators to miners, and that is the cost (viz. the **non**-aggregated cost) that must be reflected in the weight.
We should note that fullnodes are really miners with 0 hashpower, and any cost you impose on miners is a cost you impose on all fullnodes.

If you want to aggregate, you might want to do that in a separate network that does ***not*** involve Bitcoin fullnodes, and possibly allow for some kind of extraction of fees to do aggregation, then have already-aggregated transactions in the Bitcoin mempool, so that fullnodes only need validate already-aggregated transactions.

Remember, validation is run when a transaction enters the mempool, and is **not** re-run when an in-mempool transaction is seen in a block (`blocksonly` of course does not follow this as it has no mempool, but most fullnodes are not `blocksonly`).
If you intend to aggregate transactions in the mempool, then at the worst case a fullnode will be validating every non-aggregated transaction, and that is what we want to limit by increasing the weight of heavy-validation transactions.

Regards,
ZmnSCPxj