Add alternatives section to record zkproofs discussion.

This commit is contained in:
Kris Nuttycombe 2021-01-19 15:37:36 -07:00
parent 08faa9f8f8
commit becda9c543
1 changed files with 31 additions and 0 deletions

View File

@ -47,6 +47,8 @@ of this proposed change, transaction identifiers will be stable irrespective of
any possible malleation of "witness data" such as proofs and transaction
signatures.
.. _requirements-anchor:
============
Requirements
============
@ -370,6 +372,35 @@ Reference implementation
- https://github.com/zcash/librustzcash/pull/319/files
============
Alternatives
============
The zkproof components of Sapling spends and outputs could reasonably be
construed as authorizing data, rather that information that describes
value transfer. As such, it was suggested that these proof values should
not be committed to by in the transaction identifier, and should instead
be used as inputs to the signature hash. Proof data is a potential source
of transaction malleability, and as such this argument is worthy of
consideration.
As was stated in :ref:`_requirements-anchor`, a desired property of transaction
identifiers is that it should be possible for transaction signatures to commit
to the transaction identifier directly in the case that the transaction contains
no transparent inputs or in the case that only the ``SIGHASH_ALL`` flag is
used. Including proofs for signature hash computation but not as part of the
transaction identifier would make this goal unachievable.
Unlike with transparent use cases where current sources of malleability represent
a risk of double-spend attacks, in the case of a shielded-only transaction,
malleation of a zkproof value would invalidate any signatures associated with
the transaction, since in the shielded scenario all signatures must commit to
all of the transaction's shielded spends, not just a subset, and so it is not
possible for one party to a transaction to malleate their proofs in a way that
does not break the signatures of any other party to the transaction. Thus,
this source of malleability is not considered to be of concern.
==========
References
==========