zecfoundation
/
zips
mirror of https://github.com/ZcashFoundation/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fix links. Add link to reference implementation PR to ZIP 203. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2018-03-07 01:49:01 +00:00
parent ae87e03d6c
commit 274a55e841
6 changed files with 59 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
historical/calgary.md
View File

@ -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
View File

@ -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>`_

8
zip-0200.rst
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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>`_