We have a pending PR to address the `native_ccache` and `googletest`
dependencies, and we aren't going to touch `bdb`.
(cherry picked from commit 4c49af7750)
We added support for the NU5 consensus rules in v4.5.0, which alters the
block header to contain a `hashBlockCommitments` value instead of the
chain history root. However, the output of `getblocktemplate` wasn't
returning this value; once NU5 activated, the `blockcommitmentshash`
field was being set to "null" (all-zeroes).
In v4.6.0 we added full NU5 support to `getblocktemplate`, by adding a
`defaultroots` field that gave default values for `hashBlockCommitments`
and the components required to derive it. However, in doing so we
introduced a regression in the (now-deprecated) legacy fields, where
prior to NU5 activation they contained nonsense.
This commit fixes the output of `getblocktemplate` to have the intended
semantics for all fields:
- The `blockcommitmentshash` and `authdataroot` fields in `defaultroots`
are now omitted from block templates for heights before NU5 activation.
- The legacy fields now always contain the default value to be placed
into the block header (regaining their previous semantics).
Co-authored-by: Larry Ruane <larry@z.cash>
This test currently fails with submitblock returning the error
"bad-heartwood-root-in-block".
Added authdigest to GBT coinbasetxn field because we can't obtain this
via getrawtransaction.
Co-authored-by: Jack Grigg <jack@z.cash>
This will ensure that miners can use the values returned by
getblocktemplate (in particular, the block commitment hash)
to submit a valid block using the submitblock RPC.
zcash/zcash:
The `getmininginfo` RPC now omits `currentblockize` and `currentblocktx`
when a block was never assembled via RPC on this node during its current
process instantiation. The relevant RPCs are `generate` (regtest only) and
`getblocktemplate`. Blocks are also assembled when running the internal
miner (`zcashd -gen=1`), after the node mines its first block.
(cherry picked from commit bitcoin/bitcoin@fa178a6385)
This test-only change allows python (rpc) tests to specify, for example,
that NU5 should be activated at height X, without having to specify all
the previous network upgrades. Previous upgrades can (and must) still be
specified if they activate at different block heights (than, in this
example, NU5). This makes tests easier to write (and read), especially
as the number of network upgrades increases over time.
Note that this change only affects zcashd behavior in regtest mode. For
the other network modes (testnet and mainnet), the activation heights
are hard-coded in chainparams.cpp.
We aren't going to move to Clang 13 in a hotfix release. The other
dependencies passed their postponement re-evaluation date, but also
won't be updated just yet.
The "IsFromMe" logic was implemented in several places in the Bitcoin
Core wallet. We had correctly updated CWallet::IsFromMe(CTransaction)
(which was used in most places in the wallet) to check for shielded
notes being spent, but did not notice that CWalletTx::IsFromMe also
needed this check.
This bug has existed since before Zcash launched. It went unnoticed
because CWalletTx::IsFromMe was previously only called from code
used to either create purely-transparent transactions, or provide
informational output on non-critical RPC methods.
Closeszcash/zcash#5325.
- The patches `iostreams-106.patch` and `signals2-noise.patch` were
incorporated into Boost 1.75.
- The allocator access deprecation issue was fixed in Boost 1.76.
Closeszcash/zcash#4945.
This adds the double-hash message variant. The extra hash field is set
to null for block message types, and to all-ones for MSG_TX (to match
the legacy authHash value used for pre-v5 transactions in the Merkle
tree).
I tested the NU5 components of this PR by locally setting the protocol
version to 170014. I forgot to check that without that override, the
test would skip the NU5 checks. The reason it defaulted to NU5 is that
the test was reading the client version 4040150, which is indeed not
less than the NU5 protocol version ^_^;;