[ZIPs 244, 245] Specify an algorithm for non-malleable txid creation. #433
Conversation
nuttycom
force-pushed
the
wip/transaction_malleability
branch
from
2d544eb
to
6266f28
Compare
|
The commit message says ZIP 255 but it's actually ZIP 245. |
daira
changed the title
nuttycom
force-pushed
the
wip/transaction_malleability
branch
from
6266f28
to
05f86c7
Compare
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
|
Right, I'll finish those edits and remove this section this morning. In
making the edits yesterday I realized that I'd specified the txid hashes
and the witness hashes, but not the signature hash itself.
…On Wed, Jan 20, 2021 at 7:55 AM Daira Hopwood ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In zip-0244.rst
<#433 (comment)>:
> @@ -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.
This hasn't been updated to what we decided to do (zkproofs and signatures
as witness data and zkproofs excluded from signature input), right?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#433 (review)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGXR7LPMD7PBFZI55IUO3S23VFFANCNFSM4VYH4DHQ>
.
--
Kris Nuttycombe
Senior Software Engineer
kris@electriccoin.co | @nuttycom <https://twitter.com/nuttycom>
|
Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
|
A question about this ZIP arose this morning in a discussion between myself and @str4d. The current draft of this ZIP specifies that the consensus_branch_id be committed to as part of the personalization string for transaction identifier hashes. This could potentially pose a problem for off-chain protocols which require transaction identifiers to remain stable across network upgrade boundaries, such as BOLT. One possible solution to this is to add the consensus_branch_id as an optional field to the transaction and include it as effecting data, such that a TxId may optionally (and would by default) commit to a consensus branch ID after which it would be considered invalid. This would make it possible to have transaction identifiers that remain stable across network upgrade boundaries, at the cost of replay protection. What do folks think here? Do protocols that depend on the consensus branch ID have to shut down or automatically terminate at network upgrade boundaries, or is there a better way? cc/ @daira @dconnolly |
Also clarify terminology around signature hash flags vs. types.
nuttycom
force-pushed
the
wip/transaction_malleability
branch
from
07b66d4
to
a424153
Compare
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
zip-0244.rst
Outdated
| S.1: header_digest (32-byte hash output) | ||
| S.2: transparent_digest (32-byte hash output) | ||
| S.3: sprout_digest (32-byte hash output) | ||
| S.4: sapling_digest (32-byte hash output) |
There was a problem hiding this comment.
These fields have the same names as the ones in the txid_digest, which is slightly confusing because this transparent_digest is not the same, in general. Should we use *_sig_digest for the fields that can potentially be different?
There was a problem hiding this comment.
Maybe for transparent_digest alone it should have a different name? The other three are the same as for the txid digest.
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
No description provided.