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

ZIPs 205 and 206: cosmetics. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2020-03-10 17:48:44 +00:00
parent 1aa17db44e
commit fd151499d5
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
zip-0205.rst
View File

@ -13,7 +13,7 @@
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
The terms "branch" and "network upgrade" in this document are to be interpreted as
@ -84,7 +84,7 @@ peer connections.
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
The implementation is similar to that for Overwinter which was described in
The implementation is similar to that for Overwinter which was described in
[#zip-0201]_.
Once Sapling activates on testnet or mainnet, Sapling nodes should take steps to:
@ -118,13 +118,13 @@ This change does not affect mainnet.
Backward compatibility
======================
Prior to the network upgrade activating, Sapling and pre-Sapling nodes are
compatible and can connect to each other. However, Sapling nodes will have a
preference for connecting to other Sapling nodes, so pre-Sapling nodes will
Prior to the network upgrade activating, Sapling and pre-Sapling nodes are
compatible and can connect to each other. However, Sapling nodes will have a
preference for connecting to other Sapling nodes, so pre-Sapling nodes will
gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Sapling nodes can still accept the
numerically larger protocol version used by Sapling as being valid, Sapling nodes
Once the network upgrades, even though pre-Sapling nodes can still accept the
numerically larger protocol version used by Sapling as being valid, Sapling nodes
will always disconnect peers using lower protocol versions.

10
zip-0206.rst
View File

@ -13,7 +13,7 @@
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in
@ -82,7 +82,7 @@ from the set of peer connections::
/** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
The implementation is similar to that for Overwinter which was described in
The implementation is similar to that for Overwinter which was described in
[#zip-0201]_.
Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
@ -96,11 +96,11 @@ Backward compatibility
Prior to the network upgrade activating on each network, Blossom and pre-Blossom
nodes are compatible and can connect to each other. However, Blossom nodes will
have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
gradually be disconnected in the run up to activation.
Once the network upgrades, even though pre-Blossom nodes can still accept the
numerically larger protocol version used by Blossom as being valid, Blossom nodes
Once the network upgrades, even though pre-Blossom nodes can still accept the
numerically larger protocol version used by Blossom as being valid, Blossom nodes
will always disconnect peers using lower protocol versions.
Unlike Overwinter and Sapling, Blossom does not define a new transaction version.