mirror of https://github.com/zcash/zips.git
Initial sketch of transaction non-malleability requirements.
This commit is contained in:
Kris Nuttycombe
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