What is Nostr?
ZmnSCPxj [ARCHIVE] /
npub1g5z…ms3l
2023-06-07 23:21:04
in reply to nevent1q…n2mu

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-02 🗒️ Summary of this message: Aggregating ...

📅 Original date posted:2023-05-02
🗒️ Summary of this message: Aggregating proofs may be manageable, but if miners do it, full nodes must still perform non-aggregated validation, increasing costs for all. Consider a separate network for aggregation.
📝 Original message: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
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l