mirror of https://github.com/zcash/zips.git
Initial sketch of transaction non-malleability requirements.
This commit is contained in:
parent
4f1ce394fe
commit
cfe018c3b3
|
@ -0,0 +1,146 @@
|
||||||
|
::
|
||||||
|
|
||||||
|
ZIP: Unassigned {numbers are assigned by ZIP editors}
|
||||||
|
Title: Transaction Non-Malleability
|
||||||
|
Owners: Daira Hopwood <daira@electriccoin.co>
|
||||||
|
Kris Nuttycombe <kris@electriccoin.co>
|
||||||
|
Status: Draft
|
||||||
|
Category: {Consensus | Standards Track | Network | RPC | Wallet | Informational | Process}
|
||||||
|
Created: yyyy-mm-dd
|
||||||
|
License: {usually MIT}
|
||||||
|
Pull-Request: <>
|
||||||
|
|
||||||
|
Terminology
|
||||||
|
===========
|
||||||
|
|
||||||
|
{Edit this to reflect the key words that are actually used.}
|
||||||
|
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to
|
||||||
|
be interpreted as described in RFC 2119. [#RFC2119]_
|
||||||
|
|
||||||
|
The terms below are to be interpreted as follows:
|
||||||
|
|
||||||
|
{Term to be defined}
|
||||||
|
{Definition.}
|
||||||
|
{Another term}
|
||||||
|
{Definition.}
|
||||||
|
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
|
{Describe what this proposal does, typically in a few paragraphs.
|
||||||
|
|
||||||
|
The Abstract should only provide a summary of the ZIP; the ZIP should remain
|
||||||
|
complete without the Abstract.
|
||||||
|
|
||||||
|
Use links where applicable, e.g. [#protocol]_.}
|
||||||
|
|
||||||
|
|
||||||
|
Motivation
|
||||||
|
==========
|
||||||
|
|
||||||
|
In all cases, but particularly in order to support the use of transactions in
|
||||||
|
higher-level protocols, any modification of the transaction that has not been
|
||||||
|
explicitly permitted (such as via anyone-can-spend inputs) should invalidate
|
||||||
|
attestations to spend authority or to the included outputs.
|
||||||
|
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
============
|
||||||
|
|
||||||
|
- Continue to support existing functionality of the protocol (multisig,
|
||||||
|
signing modes for transparent inputs).
|
||||||
|
|
||||||
|
- Allow the use of transaction ids, and pairs of the form (transaction id,
|
||||||
|
output index) as stable identifiers.
|
||||||
|
|
||||||
|
- A sender must be able to recognize their own transaction, even given allowed
|
||||||
|
forms of malleability such as changes to witnesses.
|
||||||
|
|
||||||
|
- In the case of transparent inputs, it should be possible to create a
|
||||||
|
transaction (B) that spends the outputs from a previous transaction (A) even
|
||||||
|
before (A) has been mined. This should also be possible in the case that the
|
||||||
|
creator of (B) does not wait for confirmations of (A); (B) should remain
|
||||||
|
valid so long as any variant of (A) is eventually mined.
|
||||||
|
|
||||||
|
- It should not be possible for an attacker to malleate a transaction in a
|
||||||
|
fashion that would result in the transaction being interpreted as a
|
||||||
|
double-spend.
|
||||||
|
|
||||||
|
- It should be possible in the future to upgrade the protocol in such a fashion
|
||||||
|
that only non-malleable transactions are accepted.
|
||||||
|
|
||||||
|
- Avoid performance regressions.
|
||||||
|
|
||||||
|
|
||||||
|
Prior Art
|
||||||
|
=========
|
||||||
|
|
||||||
|
- https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
|
||||||
|
- https://bitcoinclassic.com/devel/Flexible%20Transactions.html
|
||||||
|
- SegWit
|
||||||
|
|
||||||
|
|
||||||
|
Non-requirements
|
||||||
|
================
|
||||||
|
|
||||||
|
In order to support backwards-compatibility with parts of the ecosystem that
|
||||||
|
have not yet upgraded to the non-malleable transaction format, it is not an
|
||||||
|
initial requirement that all transactions be non-malleable.
|
||||||
|
|
||||||
|
|
||||||
|
Specification
|
||||||
|
=============
|
||||||
|
|
||||||
|
- Create a new transaction format that supports non-malleability. The feature of
|
||||||
|
non-malleability and other features requiring changes to the transaction format
|
||||||
|
will only be supported for the non-malleable version, although the protocol
|
||||||
|
will remain backwards-compatible with the existing transaction format in the case
|
||||||
|
that no new features are used within a transaction.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Example subheading
|
||||||
|
------------------
|
||||||
|
|
||||||
|
{At least while the ZIP is in Draft, we encourage writing open questions and TODOs.}
|
||||||
|
|
||||||
|
Open questions
|
||||||
|
''''''''''''''
|
||||||
|
|
||||||
|
* What happens if a full node can't parse the fandangle as a doohicky?
|
||||||
|
|
||||||
|
TODO: define byte encoding for the Jabberwock.
|
||||||
|
|
||||||
|
{Feel free to copy from other ZIPs doing similar things, e.g. defining RPC calls,
|
||||||
|
consensus rules, etc.}
|
||||||
|
|
||||||
|
Valid reStructuredText
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
This is optional before publishing a PR, but to check whether a document is valid
|
||||||
|
reStructuredText, first install rst2html5::
|
||||||
|
|
||||||
|
sudo apt-get install python3-pip
|
||||||
|
sudo pip3 install rst2html5
|
||||||
|
|
||||||
|
Then, with ``zip-xxxx.rst`` in the root directory of a clone of this repo, run::
|
||||||
|
|
||||||
|
make zip-xxxx.html
|
||||||
|
|
||||||
|
and view ``zip-xxxx.html`` in a web browser.
|
||||||
|
|
||||||
|
|
||||||
|
Reference implementation
|
||||||
|
========================
|
||||||
|
|
||||||
|
{This section is entirely optional; if present, it usually gives links to zcashd or
|
||||||
|
zebrad PRs.}
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||||
|
.. [#protocol] `Zcash Protocol Specification, Version {...} or later <protocol/protocol.pdf>`_
|
||||||
|
.. [#zip-xxxx] `ZIP xxxx: Title <zip-xxxx.rst>`_
|
Loading…
Reference in New Issue