Fix links. Add link to reference implementation PR to ZIP 203.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
ae87e03d6c
commit
274a55e841
|
@ -16,9 +16,9 @@ The obvious advantage of the original implementation was avoiding structural cha
|
|||
## Scope
|
||||
|
||||
* **Chained pours** ([#121][ticket121]) mean that we should anticipate multiple pours in a transaction, specifically because the pours may require commitments from previous pours.
|
||||
* **Symmetric pours** ([#338] [ticket338]) mean that instead of separate Protect / Pour operations, a *single* Pour operation exists which takes a `vpub_in` and `vpub_out`, unifying the two operations. This requires a circuit change.
|
||||
* **Versioning semantics** ([#114] [ticket114]) require us to avoid breaking upstream tests whenever possible. We need to anticipate both changes to our own structures after launch to support new features (such as circuit changes, see #152) and potential changes to upstream transaction structures we will eventually need to rebase on top of.
|
||||
* **Cryptographic binding of pours** ([#366] [ticket366]) is necessary to ensure that (in the most common situation) it is not possible to move a pour from one transaction to another, or replace pours in a transaction without the authorization of its inputs.
|
||||
* **Symmetric pours** ([#338][ticket338]) mean that instead of separate Protect / Pour operations, a *single* Pour operation exists which takes a `vpub_in` and `vpub_out`, unifying the two operations. This requires a circuit change.
|
||||
* **Versioning semantics** ([#114][ticket114]) require us to avoid breaking upstream tests whenever possible. We need to anticipate both changes to our own structures after launch to support new features (such as circuit changes, see #152) and potential changes to upstream transaction structures we will eventually need to rebase on top of.
|
||||
* **Cryptographic binding of pours** ([#366][ticket366]) is necessary to ensure that (in the most common situation) it is not possible to move a pour from one transaction to another, or replace pours in a transaction without the authorization of its inputs.
|
||||
|
||||
[ticket121]: https://github.com/zcash/zcash/issues/121
|
||||
[ticket338]: https://github.com/zcash/zcash/issues/338
|
||||
|
@ -60,14 +60,14 @@ The heart of zerocash modifications is in `CTransaction`. The current layout is
|
|||
|
||||
#### Versioning
|
||||
|
||||
In this design, we will increment the latest `nVersion` for transactions, adding new fields to the end to encapsulate our zerocash operations ([#114] [ticket114]). Our fields must anticipate the case that no zerocash operations occur, such as in traditional or "purely cleartext" transactions.
|
||||
In this design, we will increment the latest `nVersion` for transactions, adding new fields to the end to encapsulate our zerocash operations ([#114][ticket114]). Our fields must anticipate the case that no zerocash operations occur, such as in traditional or "purely cleartext" transactions.
|
||||
|
||||
##### Alternative: Use bitflags to indicate the presence of zerocash fields
|
||||
In this alternative, we use bitflags in the `nVersion` field to indicate the presence of zerocash fields at the end. This would allow us to track upstream CTransaction changes seamlessly, *but* would indefinitely require that upstream `nVersion` bits are available to us for this purpose. Additionally, the absence of these bitflags would conflict in purpose with an empty vector of `PourTx` structures as outlined later.
|
||||
|
||||
#### PourTx
|
||||
|
||||
We add an additional field to the end of a `CTransaction`, a vector of `PourTx` structures called `vpour`. This vector is merely empty in the case of traditional transactions. Operations are allowed to reference the (commitment tree) merkle root produced by a previous operation or block for verification purposes ([#121] [ticket121]).
|
||||
We add an additional field to the end of a `CTransaction`, a vector of `PourTx` structures called `vpour`. This vector is merely empty in the case of traditional transactions. Operations are allowed to reference the (commitment tree) merkle root produced by a previous operation or block for verification purposes ([#121][ticket121]).
|
||||
|
||||
The structure of a `PourTx` is as follows:
|
||||
|
||||
|
@ -86,15 +86,15 @@ struct PourTx {
|
|||
}
|
||||
```
|
||||
|
||||
The `CTransactionSignatureSerializer` (and perhaps other components) will need to be modified so that the inputs are cryptographically bound to the `PourTx`s ([#366] [ticket366]).
|
||||
The `CTransactionSignatureSerializer` (and perhaps other components) will need to be modified so that the inputs are cryptographically bound to the `PourTx`s ([#366][ticket366]).
|
||||
|
||||
Note that this general operation has both `vpub_in` and `vpub_out` which is a generalization from the academic prototype which has separate `Protect` (with public input) and `Pour` (with public output) operations ([#338] [ticket338]).
|
||||
Note that this general operation has both `vpub_in` and `vpub_out` which is a generalization from the academic prototype which has separate `Protect` (with public input) and `Pour` (with public output) operations ([#338][ticket338]).
|
||||
|
||||
The `vin` and `vout` fields can be empty if there exist some well-formed `PourTx`s, *in contrast* to Bitcoin's invariants on these vectors.
|
||||
|
||||
##### Chained Pour Validation
|
||||
|
||||
Note that chained pours ([#121] [ticket121]) require that witnesses in a `PourTx` after the first may refer to a treestate which is not an ancestor of the block tree state after the `CTransaction` containing it is mined. For example suppose transaction `A` appears prior to transaction `B` in the same block and that each contain two `PourTx`s, `A1`, `A2`, `B1`, and `B2`. Call the tree state of the block's ancestor `T_ancestor`, and the tree state of the latest block `T_block`. The state of `T_block` will be derived from applying on top of `T_ancestor` the commits from `A1`, `A2`, `B1`, and `B2` in that order. However, `B2` may spend an output of `B1`, and if it does so, it will refer to the tree state derived by applying on top of `T_ancestor` commitments from only `B1`. Notice that a *different* output of `B1` may be spent in a later block. In *that* case, this later spend would use a proof anchored in `T_block` or some valid subsequent tree state.
|
||||
Note that chained pours ([#121][ticket121]) require that witnesses in a `PourTx` after the first may refer to a treestate which is not an ancestor of the block tree state after the `CTransaction` containing it is mined. For example suppose transaction `A` appears prior to transaction `B` in the same block and that each contain two `PourTx`s, `A1`, `A2`, `B1`, and `B2`. Call the tree state of the block's ancestor `T_ancestor`, and the tree state of the latest block `T_block`. The state of `T_block` will be derived from applying on top of `T_ancestor` the commits from `A1`, `A2`, `B1`, and `B2` in that order. However, `B2` may spend an output of `B1`, and if it does so, it will refer to the tree state derived by applying on top of `T_ancestor` commitments from only `B1`. Notice that a *different* output of `B1` may be spent in a later block. In *that* case, this later spend would use a proof anchored in `T_block` or some valid subsequent tree state.
|
||||
|
||||
##### Script-based Signatures
|
||||
|
||||
|
@ -123,10 +123,10 @@ Various parts of this design can be implemented concurrently and iteratively.
|
|||
### Stage 2: Concurrent tasks
|
||||
Each of the following tasks to complete the redesign can be done independently.
|
||||
|
||||
* Add old RPC commands. ([#527] [ticket527])
|
||||
* `CScript` scheme to enforce cryptographic binding of the transaction to the pour. ([#529] [ticket529])
|
||||
* Chained pours which allow pours to reference merkle roots produced by other pours. ([#555] [ticket555])
|
||||
* A zerocash-specific versioning field can be added, along with upstream interaction semantics. ([#114] [ticket114])
|
||||
* Add old RPC commands. ([#527][ticket527])
|
||||
* `CScript` scheme to enforce cryptographic binding of the transaction to the pour. ([#529][ticket529])
|
||||
* Chained pours which allow pours to reference merkle roots produced by other pours. ([#555][ticket555])
|
||||
* A zerocash-specific versioning field can be added, along with upstream interaction semantics. ([#114][ticket114])
|
||||
|
||||
[ticket527]: https://github.com/zcash/zcash/issues/527
|
||||
[ticket529]: https://github.com/zcash/zcash/issues/529
|
||||
|
|
36
zip-0143.rst
36
zip-0143.rst
|
@ -17,9 +17,9 @@ Terminology
|
|||
|
||||
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#ZIP0200]_
|
||||
The terms "branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200. [#zip-0200]_
|
||||
|
||||
The term "Overwinter" in this document is to be interpreted as described in ZIP 201. [#ZIP0201]_
|
||||
The term "Overwinter" in this document is to be interpreted as described in ZIP 201. [#zip-0201]_
|
||||
|
||||
|
||||
Abstract
|
||||
|
@ -83,20 +83,20 @@ A new transaction digest algorithm is defined::
|
|||
c. value of the output spent by this input (8-byte little endian)
|
||||
d. nSequence of the input (4-byte little endian)
|
||||
|
||||
The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, [#BIP0143]_ with
|
||||
replay protection inspired by BUIP-HF v1.2. [#BUIP-HF]_
|
||||
The new algorithm is based on the Bitcoin transaction digest algorithm defined in BIP 143, [#bip-0143]_ with
|
||||
replay protection inspired by BUIP-HF v1.2. [#buip-HF]_
|
||||
|
||||
The new algorithm MUST be used for signatures created over the Overwinter transaction format. [#ZIP0202]_
|
||||
The new algorithm MUST be used for signatures created over the Overwinter transaction format. [#zip-0202]_
|
||||
Combined with the new consensus rule that v1 and v2 transaction formats will be invalid from the Overwinter
|
||||
upgrade, [#ZIP0202]_ this effectively means that all transaction signatures from the Overwinter activation
|
||||
height will use the new algorithm. [#ZIP0201]_
|
||||
upgrade, [#zip-0202]_ this effectively means that all transaction signatures from the Overwinter activation
|
||||
height will use the new algorithm. [#zip-0201]_
|
||||
|
||||
The BLAKE2b-256 personalization field [#BLAKE2-personalization]_ is set to::
|
||||
|
||||
"ZcashSigHash" || CONSENSUS_BRANCH_ID
|
||||
|
||||
``CONSENSUS_BRANCH_ID`` is the little-endian encoding of ``BRANCH_ID`` for the epoch of the block containing
|
||||
the transaction. [#ZIP0200]_ Domain separation of the signature hash across parallel branches provides replay
|
||||
the transaction. [#zip-0200]_ Domain separation of the signature hash across parallel branches provides replay
|
||||
protection: transactions targeted for one branch will have invalid signatures on other branches.
|
||||
|
||||
Transaction creators MUST specify the epoch they want their transaction to be mined in. Across a network
|
||||
|
@ -121,12 +121,12 @@ The items 7, 9, 10a, 10d have the same meaning as the original algorithm from Bi
|
|||
1: ``header``
|
||||
`````````````
|
||||
Deserialized into two transaction properties: ``fOverwintered`` and ``nVersion``. For transactions that use
|
||||
this transaction digest algorithm, ``fOverwintered`` is always set. [#ZIP0202]_
|
||||
this transaction digest algorithm, ``fOverwintered`` is always set. [#zip-0202]_
|
||||
|
||||
2: ``nVersionGroupId``
|
||||
``````````````````````
|
||||
Provides domain separation of ``nVersion``. It is only defined if ``fOverwintered`` is set, which means that
|
||||
it is always defined for transactions that use this algorithm. [#ZIP0202]_
|
||||
it is always defined for transactions that use this algorithm. [#zip-0202]_
|
||||
|
||||
3: ``hashPrevouts``
|
||||
```````````````````
|
||||
|
@ -173,7 +173,7 @@ it is always defined for transactions that use this algorithm. [#ZIP0202]_
|
|||
|
||||
8: ``nExpiryHeight``
|
||||
````````````````````
|
||||
The block height after which the transaction becomes unilaterally invalid, and can never be mined. [#ZIP0203]_
|
||||
The block height after which the transaction becomes unilaterally invalid, and can never be mined. [#zip-0203]_
|
||||
|
||||
10b: ``scriptCode``
|
||||
```````````````````
|
||||
|
@ -293,7 +293,7 @@ TBC
|
|||
Deployment
|
||||
==========
|
||||
|
||||
This proposal is deployed with the Overwinter network upgrade. [#ZIP0201]_
|
||||
This proposal is deployed with the Overwinter network upgrade. [#zip-0201]_
|
||||
|
||||
|
||||
Backward compatibility
|
||||
|
@ -313,8 +313,6 @@ https://github.com/zcash/zcash/pull/2903
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#ZIP0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/pull/128>`_
|
||||
.. [#ZIP0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/pull/134>`_
|
||||
.. [#wiki-checksig] https://en.bitcoin.it/wiki/OP_CHECKSIG
|
||||
.. [#zcash-protocol] `Zcash Protocol Specification, Section 4.6 <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`_
|
||||
.. [#quadratic]
|
||||
|
@ -322,11 +320,13 @@ References
|
|||
* `New Bitcoin vulnerability: A transaction that takes at least 3 minutes to verify <https://bitcointalk.org/?topic=140078>`_
|
||||
* `The Megatransaction: Why Does It Take 25 Seconds? <http://rusty.ozlabs.org/?p=522>`_
|
||||
.. [#offline-wallets] `SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data <https://bitcointalk.org/index.php?topic=181734.0>`_
|
||||
.. [#BIP0143] `BIP 143: Transaction Signature Verification for Version 0 Witness Program <https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki>`_
|
||||
.. [#BUIP-HF] `BUIP-HF Digest for replay protected signature verification across hard forks, version 1.2 <https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/abc/replay-protected-sighash.md>`_
|
||||
.. [#ZIP0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/pull/133>`_
|
||||
.. [#bip-0143] `BIP 143: Transaction Signature Verification for Version 0 Witness Program <https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki>`_
|
||||
.. [#buip-HF] `BUIP-HF Digest for replay protected signature verification across hard forks, version 1.2 <https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/abc/replay-protected-sighash.md>`_
|
||||
.. [#BLAKE2-personalization] `"BLAKE2: simpler, smaller, fast as MD5", Section 2.8 <https://blake2.net/blake2.pdf>`_
|
||||
.. [#01-change] In the original algorithm, a ``uint256`` of ``0x0000......0001`` is committed if the input
|
||||
index for a ``SINGLE`` signature is greater than or equal to the number of outputs. In this ZIP a
|
||||
``0x0000......0000`` is commited, without changing the semantics.
|
||||
.. [#ZIP0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/pull/131>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
|
||||
|
|
|
@ -218,11 +218,11 @@ https://github.com/zcash/zcash/pull/2898
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] https://tools.ietf.org/html/rfc2119
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#consensual-currency] https://z.cash/blog/consensual-currency.html
|
||||
.. [#release-lifecycle]
|
||||
- https://z.cash/blog/release-cycle-and-lifetimes.html
|
||||
- https://z.cash/blog/release-cycle-update.html
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/pull/133>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/pull/129>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/pull/134>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
|
|
10
zip-0201.rst
10
zip-0201.rst
|
@ -240,11 +240,11 @@ https://github.com/zcash/zcash/pull/2919
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] https://tools.ietf.org/html/rfc2119
|
||||
.. [#zip-0143] `Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/pull/129>`_
|
||||
.. [#zip-0200] `Network Upgrade Activation Mechanism <https://github.com/zcash/zips/pull/128/>`_
|
||||
.. [#zip-0202] `Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/pull/133>`_
|
||||
.. [#zip-0203] `Transaction Expiry <https://github.com/zcash/zips/pull/131>`_
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0202] `ZIP 202: Version 3 Transaction Format for Overwinter <https://github.com/zcash/zips/blob/master/zip-0202.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
|
||||
.. [#bitcoin-verson] https://en.bitcoin.it/wiki/Protocol_documentation#version
|
||||
.. [#bitcoin-version-handshake] https://en.bitcoin.it/wiki/Version_Handshake
|
||||
.. [#eclipse-attack] `Eclipse Attacks on Bitcoin’s Peer-to-Peer Network <https://eprint.iacr.org/2015/263>`_
|
||||
|
|
15
zip-0202.rst
15
zip-0202.rst
|
@ -249,14 +249,9 @@ https://github.com/zcash/zcash/pull/2925
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#RFC2119] https://tools.ietf.org/html/rfc2119
|
||||
.. [#zip-0143] `Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/pull/129>`_
|
||||
.. [#zip-0200] `Network Upgrade Activation Mechanism <https://github.com/zcash/zips/pull/128/>`_
|
||||
.. [#zip-0201] `Network Handshaking for Overwinter <https://github.com/zcash/zips/pull/134/>`_
|
||||
.. [#zip-0203] `Transaction Expiry <https://github.com/zcash/zips/pull/131>`_
|
||||
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||
.. [#zip-0143] `ZIP 143: Transaction Signature Verification for Overwinter <https://github.com/zcash/zips/blob/master/zip-0143.rst>`_
|
||||
.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism <https://github.com/zcash/zips/blob/master/zip-0200.rst>`_
|
||||
.. [#zip-0201] `ZIP 201: Network Handshaking for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
.. [#zip-0203] `ZIP 203: Transaction Expiry <https://github.com/zcash/zips/blob/master/zip-0203.rst>`_
|
||||
.. [#versiongroupid] `OVERWINTER_VERSION_GROUP_ID <https://github.com/zcash/zcash/pull/2925/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR311>`_
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
18
zip-0203.rst
18
zip-0203.rst
|
@ -68,16 +68,28 @@ To view:
|
|||
listtransactions has a new filter attribute, showing expired transactions only:
|
||||
listtransactions "*" 10 0 "expired"
|
||||
|
||||
WalletTxToJSON shows a boolean expired true/false
|
||||
WalletTxToJSON shows a boolean expired true/false.
|
||||
|
||||
Config
|
||||
-------
|
||||
|
||||
Default will be user configurable with flag `txblockexpirydelta`
|
||||
Default will be user configurable with flag `txblockexpirydelta`.
|
||||
|
||||
`--txblockexpirydelta=100`
|
||||
|
||||
Deployment
|
||||
------------
|
||||
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in [ZIP 201](https://github.com/zcash/zips/blob/master/zip-0201.rst)
|
||||
This feature will be deployed with Overwinter. The activation blockheight proposal is in [#zip-0201]_.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
https://github.com/zcash/zcash/pull/2874
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#zip-0201] `ZIP 201: Network Peer Management for Overwinter <https://github.com/zcash/zips/blob/master/zip-0201.rst>`_
|
||||
|
|
Loading…
Reference in New Issue