Merge remote-tracking branch 'upstream/master' into hotfix-v2.1.2-2-golden
This commit is contained in:
commit
86d631bf36
|
@ -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">
|
||||
===========
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: "zcash-2.1.2-3"
|
||||
name: "zcash-3.0.0-rc1"
|
||||
enable_cache: true
|
||||
distro: "debian"
|
||||
suites:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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/>.
|
||||
|
|
|
@ -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]
|
||||
|
|
|
@ -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/>.
|
||||
|
|
|
@ -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.
|
|
@ -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()
|
||||
|
|
@ -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;
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
54
src/main.cpp
54
src/main.cpp
|
@ -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))
|
||||
|
|
|
@ -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;
|
||||
|
|
Loading…
Reference in New Issue