Date: Sun, 30 Apr 2023 02:15:50 +0000
To: Weiji Guo <weiji.g@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xNzSDtvj-BH4EW9eJMqn_yAiVUEiggnS3WIrvLml6gGAZ6CPADO9pbPV4B30txzSY9laEmX3ckXX8L2Hu18ZrWMUjMH23csL-YK-mDse6DY=@protonmail.com>
In-Reply-To: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
References: <CA+ydi=LtskFh89TW75=CBwbdZzWR-ZjWS77TnrF4G+xUfm8z+Q@mail.gmail.com>
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
Precedence: list

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