From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Weiji Guo <weiji.g@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization
Date: Tue, 02 May 2023 15:01:01 +0000 [thread overview]
Message-ID: <s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com> (raw)
In-Reply-To: <CA+ydi=K7kePFPXbTP6S63SdddORnc6nVoHqR4gDVoeX3uY-S-Q@mail.gmail.com>
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
next prev parent reply other threads:[~2023-05-02 15:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 8:29 [bitcoin-dev] proposal: new opcode OP_ZKP to enable ZKP-based spending authorization Weiji Guo
2023-04-30 2:15 ` ZmnSCPxj
2023-05-01 12:46 ` Weiji Guo
2023-05-02 15:01 ` ZmnSCPxj [this message]
2023-05-04 15:31 ` Weiji Guo
2023-05-04 17:13 ` ZmnSCPxj
2023-05-05 23:06 ` Weiji Guo
2023-05-06 2:51 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='s3urNahBotY-aYGaQyY7wz2Sh8UXbqHX2PvZyRcyaMJF6MjUrabv0p_ytE3m1Cu9r79MY649RoulaBPuqGLrSD8qwOfCS-n-HymOEyih5yQ=@protonmail.com' \
--to=zmnscpxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=weiji.g@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox