Merge remote-tracking branch 'upstream/master' into hotfix-v2.1.2-2-golden

This commit is contained in:
Kris Nuttycombe 2020-05-21 16:49:24 -06:00
commit 86d631bf36
15 changed files with 218 additions and 39 deletions

View File

@ -1,4 +1,4 @@
Zcash 2.1.2-3
Zcash 3.0.0-rc1
<img align="right" width="120" height="80" src="doc/imgs/logo.png">
===========

View File

@ -1,9 +1,9 @@
dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
AC_PREREQ([2.60])
define(_CLIENT_VERSION_MAJOR, 2)
define(_CLIENT_VERSION_MINOR, 1)
define(_CLIENT_VERSION_REVISION, 2)
define(_CLIENT_VERSION_BUILD, 53)
define(_CLIENT_VERSION_MAJOR, 3)
define(_CLIENT_VERSION_MINOR, 0)
define(_CLIENT_VERSION_REVISION, 0)
define(_CLIENT_VERSION_BUILD, 25)
define(_ZC_BUILD_VAL, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, m4_incr(_CLIENT_VERSION_BUILD), m4_eval(_CLIENT_VERSION_BUILD < 50), 1, m4_eval(_CLIENT_VERSION_BUILD - 24), m4_eval(_CLIENT_VERSION_BUILD == 50), 1, , m4_eval(_CLIENT_VERSION_BUILD - 50)))
define(_CLIENT_VERSION_SUFFIX, m4_if(m4_eval(_CLIENT_VERSION_BUILD < 25), 1, _CLIENT_VERSION_REVISION-beta$1, m4_eval(_CLIENT_VERSION_BUILD < 50), 1, _CLIENT_VERSION_REVISION-rc$1, m4_eval(_CLIENT_VERSION_BUILD == 50), 1, _CLIENT_VERSION_REVISION, _CLIENT_VERSION_REVISION-$1)))
define(_CLIENT_VERSION_IS_RELEASE, true)

View File

@ -1,3 +1,9 @@
zcash (3.0.0~rc1) stable; urgency=medium
* 3.0.0-rc1 release.
-- Electric Coin Company <team@electriccoin.co> Thu, 21 May 2020 07:34:53 -0600
zcash (2.1.2+3) stable; urgency=medium
* 2.1.2-3 release.

View File

@ -1,5 +1,5 @@
---
name: "zcash-2.1.2-3"
name: "zcash-3.0.0-rc1"
enable_cache: true
distro: "debian"
suites:

View File

@ -10,7 +10,7 @@ $(package)_config_opts=
define $(package)_preprocess_cmds
patch -p1 < $($(package)_patch_dir)/1.0.15-pubkey-validation.diff && \
patch -p1 < $($(package)_patch_dir)/1.0.15-signature-validation.diff && \
cd $($(package)_build_subdir); ./autogen.sh
cd $($(package)_build_subdir); DO_NOT_UPDATE_CONFIG_SCRIPTS=1 ./autogen.sh
endef
define $(package)_config_cmds

View File

@ -1,9 +1,9 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13.
.TH ZCASH-CLI "1" "May 2020" "zcash-cli v2.1.2-3" "User Commands"
.TH ZCASH-CLI "1" "May 2020" "zcash-cli v3.0.0-rc1" "User Commands"
.SH NAME
zcash-cli \- manual page for zcash-cli v2.1.2-3
zcash-cli \- manual page for zcash-cli v3.0.0-rc1
.SH DESCRIPTION
Zcash RPC client version v2.1.2\-3
Zcash RPC client version v3.0.0\-rc1
.PP
In order to ensure you are adequately protecting your privacy when using Zcash,
please see <https://z.cash/support/security/>.

View File

@ -1,9 +1,9 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13.
.TH ZCASH-TX "1" "May 2020" "zcash-tx v2.1.2-3" "User Commands"
.TH ZCASH-TX "1" "May 2020" "zcash-tx v3.0.0-rc1" "User Commands"
.SH NAME
zcash-tx \- manual page for zcash-tx v2.1.2-3
zcash-tx \- manual page for zcash-tx v3.0.0-rc1
.SH DESCRIPTION
Zcash zcash\-tx utility version v2.1.2\-3
Zcash zcash\-tx utility version v3.0.0\-rc1
.SS "Usage:"
.TP
zcash\-tx [options] <hex\-tx> [commands]

View File

@ -1,9 +1,9 @@
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.13.
.TH ZCASHD "1" "May 2020" "zcashd v2.1.2-3" "User Commands"
.TH ZCASHD "1" "May 2020" "zcashd v3.0.0-rc1" "User Commands"
.SH NAME
zcashd \- manual page for zcashd v2.1.2-3
zcashd \- manual page for zcashd v3.0.0-rc1
.SH DESCRIPTION
Zcash Daemon version v2.1.2\-3
Zcash Daemon version v3.0.0\-rc1
.PP
In order to ensure you are adequately protecting your privacy when using Zcash,
please see <https://z.cash/support/security/>.

View File

@ -4,3 +4,29 @@ release-notes at release time)
Notable changes
===============
The mainnet activation of the Heartwood network upgrade is supported by this
release, with an activation height of 903000, which should occur in the middle
of July — following the targeted EOS halt of our 2.1.2-3 release. Please upgrade
to this release, or any subsequent release, in order to follow the Heartwood
network upgrade.
The following two ZIPs are being deployed as part of this upgrade:
- [ZIP 213: Shielded Coinbase](https://zips.z.cash/zip-0213)
- [ZIP 221: FlyClient - Consensus-Layer Changes](https://zips.z.cash/zip-0221)
In order to help the ecosystem prepare for the mainnet activiation, Heartwood
has already been activated on the Zcash testnet. Any node version 2.1.2 or
higher, including this release, supports the Heartwood activation on testnet.
## Mining to Sapling addresses
After the mainnet activation of Heartwood, miners can mine directly into a
Sapling shielded address. Miners should wait until after Heartwood activation
before they make changes to their configuration to leverage this new feature.
After activation of Heartwood, miners can add `mineraddress=SAPLING_ADDRESS` to
their `zcash.conf` file, where `SAPLING_ADDRESS` represents a Sapling address
that can be generated locally with the `z_getnewaddress` RPC command. Restart
your node, and block templates produced by the `getblocktemplate` RPC command
will now have coinbase transactions that mine directly into this shielded
address.

View File

@ -0,0 +1,120 @@
Notable changes
===============
The mainnet activation of the Heartwood network upgrade is supported by this
release, with an activation height of 903000, which should occur in the middle
of July — following the targeted EOS halt of our 2.1.2-3 release. Please upgrade
to this release, or any subsequent release, in order to follow the Heartwood
network upgrade.
The following two ZIPs are being deployed as part of this upgrade:
- [ZIP 213: Shielded Coinbase](https://zips.z.cash/zip-0213)
- [ZIP 221: FlyClient - Consensus-Layer Changes](https://zips.z.cash/zip-0221)
In order to help the ecosystem prepare for the mainnet activiation, Heartwood
has already been activated on the Zcash testnet. Any node version 2.1.2 or
higher, including this release, supports the Heartwood activation on testnet.
## Mining to Sapling addresses
After the mainnet activation of Heartwood, miners can mine directly into a
Sapling shielded address. Miners should wait until after Heartwood activation
before they make changes to their configuration to leverage this new feature.
After activation of Heartwood, miners can add `mineraddress=SAPLING_ADDRESS` to
their `zcash.conf` file, where `SAPLING_ADDRESS` represents a Sapling address
that can be generated locally with the `z_getnewaddress` RPC command. Restart
your node, and block templates produced by the `getblocktemplate` RPC command
will now have coinbase transactions that mine directly into this shielded
address.
Changelog
=========
Aaron Clauson (1):
Minimal code changes to allow msvc compilation.
Adam Langley (1):
Switch memory_cleanse implementation to BoringSSL's to ensure memory clearing even with link-time optimization.
Alfredo Garcia (12):
fix rpc testcase
add blockheight, blockindex and blocktime to z_listreceivedbyaddress
change time to blocktime in help
add status to transactions
minor fix
minor cleanup style, var names
Add a new safe chars rule for node version string
fix wallet nullifiers test
Fix typo
add a test case
implement z_getnotescount api call
remove not needed help parameters to dump and import impl
Ben Wilson (4):
Added Dockerfile to contrib with README
Fixed README grammar, reuse Dockerfile vars
Fixed Docker README grammar
Dockerfiles for zcashd CI builds
Daira Hopwood (2):
Fix a null pointer dereference that occurs when formatting an error message, if we haven't activated an upgrade as expected.
Explicitly assert that chainActive[upgrade.nActivationHeight] is non-null at this point.
Dimitris Apostolou (1):
Fix typos
Jack Grigg (5):
Use BOOST_SCOPE_EXIT_TPL to clean and free datValue in CDB::Read
Improve memory_cleanse documentation
Add NU4 to upgrade list
Add NU4 test helpers
Update URLs for prior network upgrades
Jonathan "Duke" Leto (1):
Add confirmations to z_listreceivedbyaddress
Kris Nuttycombe (21):
Add a test reproducing the off-by-one error.
Check network reunification.
Narrow down the test case.
Make the test reproduce the actual off-by-one error in rewind length.
Fix #4119.
The last valid height condition reads better flipped.
Restart node in a chain split state to allow the test to complete.
Trivial comment.
Remove option to load new blocks from ConnectTip
Make condition closer to original, Fix incorrect comment.
Ensure that we don't pass a null block pointer to ConnectTip.
Update all crates.
Update to the Cargo V2 lockfile format.
Clean up imports in sapling_rewind_check.py
Use `%x` formatter for branch id hex string in test_framework/util.py
Update qa/rpc-tests/test_framework/mininode.py
Update qa/rpc-tests/sapling_rewind_check.py
Add Zcash copyright to sapling_rewind_check.py
Update test description and clarify internal comments.
Revert "Update qa/rpc-tests/sapling_rewind_check.py"
Remove unused imports.
Sean Bowe (6):
Update minimum chain work on testnet to reflect Heartwood activation.
Pass DO_NOT_UPDATE_CONFIG_SCRIPTS=1 to autogen.sh in libsodium dependency, to avoid updating config scripts over the network.
Set the Heartwood activation height to 903000.
Bump the protocol version, as this node supports Heartwood on mainnet.
make-release.py: Versioning changes for 3.0.0-rc1.
make-release.py: Updated manpages for 3.0.0-rc1.
Taylor Hornby (2):
Add univalue to updatecheck.py and update univalue, removing calls to deprecated methods
Avoid names starting with __.
Thomas Snider (1):
[wallet] Securely erase potentially sensitive keys/values
Tim Ruffing (2):
Clean up logic in memory_cleanse() for MSVC
Improve documentation of memory_cleanse()
therealyingtong (1):
Fix off-by-one error in CreateNewBlock()

View File

@ -120,8 +120,7 @@ public:
consensus.vUpgrades[Consensus::UPGRADE_BLOSSOM].nProtocolVersion = 170009;
consensus.vUpgrades[Consensus::UPGRADE_BLOSSOM].nActivationHeight = 653600;
consensus.vUpgrades[Consensus::UPGRADE_HEARTWOOD].nProtocolVersion = 170011;
consensus.vUpgrades[Consensus::UPGRADE_HEARTWOOD].nActivationHeight =
Consensus::NetworkUpgrade::NO_ACTIVATION_HEIGHT;
consensus.vUpgrades[Consensus::UPGRADE_HEARTWOOD].nActivationHeight = 903000;
consensus.vUpgrades[Consensus::UPGRADE_NU4].nProtocolVersion = 170013;
consensus.vUpgrades[Consensus::UPGRADE_NU4].nActivationHeight =
Consensus::NetworkUpgrade::NO_ACTIVATION_HEIGHT;
@ -349,7 +348,7 @@ public:
consensus.nFutureTimestampSoftForkHeight = consensus.vUpgrades[Consensus::UPGRADE_BLOSSOM].nActivationHeight + 6;
// The best chain should have at least this much work.
consensus.nMinimumChainWork = uint256S("0x0000000000000000000000000000000000000000000000000000001dbb4c4224");
consensus.nMinimumChainWork = uint256S("0x00000000000000000000000000000000000000000000000000000025ba29b8d3");
pchMessageStart[0] = 0xfa;
pchMessageStart[1] = 0x1a;

View File

@ -15,10 +15,10 @@
*/
//! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it
#define CLIENT_VERSION_MAJOR 2
#define CLIENT_VERSION_MINOR 1
#define CLIENT_VERSION_REVISION 2
#define CLIENT_VERSION_BUILD 53
#define CLIENT_VERSION_MAJOR 3
#define CLIENT_VERSION_MINOR 0
#define CLIENT_VERSION_REVISION 0
#define CLIENT_VERSION_BUILD 25
//! Set to true for release, false for prerelease or test build
#define CLIENT_VERSION_IS_RELEASE true

View File

@ -8,10 +8,10 @@
// Deprecation policy:
// * Shut down 16 weeks' worth of blocks after the estimated release block height.
// * A warning is shown during the 2 weeks' worth of blocks prior to shut down.
static const int APPROX_RELEASE_HEIGHT = 824273;
static const int APPROX_RELEASE_HEIGHT = 838929;
// static const int WEEKS_UNTIL_DEPRECATION = 16;
// static const int DEPRECATION_HEIGHT = APPROX_RELEASE_HEIGHT + (WEEKS_UNTIL_DEPRECATION * 7 * 24 * 48);
static const int DEPRECATION_HEIGHT = 901475;
static const int DEPRECATION_HEIGHT = 973713;
// Number of blocks before deprecation to warn users
static const int DEPRECATION_WARN_LIMIT = 14 * 24 * 48; // 2 weeks

View File

@ -1838,20 +1838,48 @@ bool IsInitialBlockDownload(const CChainParams& chainParams)
// we are not on the correct chain. As we have already checked that the current
// chain satisfies the minimum chain work, this is likely an adversarial situation
// where the node is being fed a fake alternate chain; shut down for safety.
//
// Note that this depends on the assumption that if we set hashActivationBlock for
// any upgrade, we also update nMinimumChainWork to be past that upgrade.
//
auto upgrade = chainParams.GetConsensus().vUpgrades[idx];
if (upgrade.hashActivationBlock && (
!chainParams.GetConsensus().NetworkUpgradeActive(chainActive.Height(), Consensus::UpgradeIndex(idx))
|| chainActive[upgrade.nActivationHeight]->GetBlockHash() != upgrade.hashActivationBlock.get()
)) {
AbortNode(
strprintf(
"%s: Activation block hash mismatch for the %s network upgrade (expected %s, found %s). Likely adversarial condition; shutting down for safety.",
__func__,
NetworkUpgradeInfo[idx].strName,
upgrade.hashActivationBlock.get().GetHex(),
chainActive[upgrade.nActivationHeight]->GetBlockHash().GetHex()),
_("We are on a chain with sufficient work, but the network upgrade checkpoints do not match. Your node may be under attack! Shutting down for safety."));
return true;
if (upgrade.hashActivationBlock) {
if (!chainParams.GetConsensus().NetworkUpgradeActive(chainActive.Height(), Consensus::UpgradeIndex(idx))) {
AbortNode(
strprintf(
"%s: We are on a chain with sufficient work, but the %s network upgrade has not activated as expected.\n"
"Likely adversarial condition; shutting down for safety.\n"
" nChainWork=%s\n nMinimumChainWork=%s\n tip height=%d\n upgrade height=%d",
__func__,
NetworkUpgradeInfo[idx].strName,
chainActive.Tip()->nChainWork.GetHex(),
chainParams.GetConsensus().nMinimumChainWork.GetHex(),
chainActive.Height(),
upgrade.nActivationHeight),
_("We are on a chain with sufficient work, but an expected network upgrade has not activated. Your node may be under attack! Shutting down for safety."));
return true;
}
// If an upgrade is active, we must be past its activation height.
assert(chainActive[upgrade.nActivationHeight]);
if (chainActive[upgrade.nActivationHeight]->GetBlockHash() != upgrade.hashActivationBlock.get()) {
AbortNode(
strprintf(
"%s: We are on a chain with sufficient work, but the activation block hash for the %s network upgrade is not as expected.\n"
"Likely adversarial condition; shutting down for safety.\n",
" nChainWork=%s\n nMinimumChainWork=%s\n tip height=%d\n upgrade height=%d\n expected hash=%s\n actual hash=%s",
__func__,
NetworkUpgradeInfo[idx].strName,
chainActive.Tip()->nChainWork.GetHex(),
chainParams.GetConsensus().nMinimumChainWork.GetHex(),
chainActive.Height(),
upgrade.nActivationHeight,
upgrade.hashActivationBlock.get().GetHex(),
chainActive[upgrade.nActivationHeight]->GetBlockHash().GetHex()),
_("We are on a chain with sufficient work, but the network upgrade checkpoints do not match. Your node may be under attack! Shutting down for safety."));
return true;
}
}
}
if (chainActive.Tip()->GetBlockTime() < (GetTime() - nMaxTipAge))

View File

@ -9,7 +9,7 @@
* network protocol versioning
*/
static const int PROTOCOL_VERSION = 170010;
static const int PROTOCOL_VERSION = 170011;
//! initial proto version, to be increased after version/verack negotiation
static const int INIT_PROTO_VERSION = 209;