The test fails during the final `z_sendmany`, because it is selecting a
note that was detected before restarting the node. Because we force the
wallet to call `SetBestChain` on every block, the wallet doesn't need to
rescan on restart, and thus doesn't repopulate the `position` field of
the in-memory note.
This issue went unnoticed in existing tests that exercise node restarts,
because the RPC tests are fast enough that they never pass the 10-minute
timeout for writing the wallet state. This commit adds a regtest-only
config option that disables the lazy writing.
Make consistent use of "pool", "address type" and "receiver type",
in RPC documentaion, and deprecate bare uses of "type" in RPC APIs.
Fixes#5534
Co-authored-by: str4d <thestr4d@gmail.com>
Orchard output ordering is no longer deterministic, as we now shuffle
spends and outputs during bundle building. But we _can_ still check that
the action index of a note being spent is correct.
Also fixes a bug in the `nuparams` helper, which would have caused MSB
zeroes in consensus branch IDs to not be rendered in the `-nuparams`
option. This hadn't been encountered because we haven't yet generated a
consensus branch ID with a zero MSB.
We need to bump the `zcashd` protocol version because the new rules are
not compatible with existing rules followed by 170015 nodes, but we
_also_ need to ensure we can still bump it again once we set the testnet
reactivation height (changing node network behaviour again). This commit
also enables RPC tests to run (because previously the nodes considered
each other to be too old for NU5 to be active, and were disconnecting).
This includes:
- `orchard =0.1.0-beta.3` which includes the final circuit changes.
- The new NU5 consensus branch ID.
- Updated ZIP 244 test vectors (which use the NU5 consensus branch ID).
- The legacy_random source should only contain Sprout addresses (as
zcashd now only derives transparent addresses from the mnemonic seed).
- Sapling addresses should appear in the mnemonic_seed source, not the
legacy_seed source (as zcashd no longer ever generates keys there).
The RPC test also now has several additional checks:
- `listaddresses` does not return duplicate addresses (an address can
only come from a single source).
- Address sets are now explicitly checked (to ensure that there are no
unexpected addresses under the checked sources).
We now have a full roster of privacy policies. We can graph the
relationships between the policies; arrows point from more-private to
less-private, and each policy is permitted to reveal information covered
by all policies pointing to it (in addition to the extra information it
is permitted to reveal).
FullPrivacy
v
AllowRevealedAmounts
v v
AllowRevealedRecipients ---- AllowRevealedSenders
v / v
AllowFullyTransparent <- AllowLinkingAccountAddresses
v v
NoPrivacy
The synthetic `LegacyCompat` policy now uses the `AllowFullyTransparent`
policy for backwards compatibility, and the `FullPrivacy` policy if the
sender or recipients involve Unified Addresses.
Closeszcash/zcash#5677.
Closeszcash/zcash#5678.
This replaces the bool argument with a string argument, enabling us to
add additional privacy strategies. We also alter the default to be
backwards-compatible with existing RPC method usage, by only enabling
the strongest checks if a Unified Address is involved.
Closeszcash/zcash#5676.
Prior to this change, calling `join_network` after a network split
only worked in the case that no new non-coinbase transactions were
created during the network partition; in the case that such a
transaction was created, `join_network` would fail when waiting
for mempool synchronization, because zcashd nodes do not.
automatically broadcast their mempool contents on restart.
This change modifies `setup_network` to wait for mempool synchronization
or not on the basis of a newly added do_mempool_sync flag. In the
case of `join_network`, this flag is set to `False`; the default value
is set to `True` to preserve previous functionality elsewhere.
Tests should explicitly use the `resendwallettransactions` RPC method
to ensure that mempool transactions are rebroadcast before attempting
to synchronize the network after a `join_network` call.
We can't actually test rollback via RPC tests until
wallet persistence is implemented. This implements
a rollback scenario that will should pass after wallet
persistence is implemented.
The addition of `OrchardRawAddress` to `RecipientAddress` drives most of
the changes in this commit, which enable `z_sendmany` to send funds to
addresses in the Orchard pool once NU5 activates.
We also add Orchard-specific information to several RPCs in order for
tests to pass:
- `z_listunifiedreceivers`
- `z_getbalanceforaccount`
- `z_getbalanceforviewingkey`
This fixes a potential bug with importing the mnemonic into a third
party transparent wallet. Previously, if a user called `getnewaddress`,
made a bunch of transactions that generated at least 20 change
addresses, and then called `getnewaddress` again, the two external
addresses would be separated by a gap of more than 20. If this mnemonic
were imported into a third party transparent wallet, the wallet would
not detect any funds in the second (or subsequent) transparent addresses
because it would detect 20 unused addresses in a row (via the BIP 44
default gap limit).
Now, we track external and internal keys separately; repeated calls to
`getnewaddress` will return addresses for sequential keys. This has the
added benefit that the sequence of `getnewaddress` outputs will be the
same after restoring from a backup.
We also add a `type` field to the output objects (matching the field in
`z_viewtransaction`), now that the output type can't be distinguished
solely from the address encoding.
The ZTXOSelector type allows selection of previous Zcash
transaction outputs (both transparent outputs and shielded notes)
on the basis of either a (legacy) bare address, or for a
BIP-44 account.
We now use the empty array of pools to indicate that the default pools
should be used when providing a diversifier index parameter, instead of
needing a default sentinel value for the diversifier index parameter
(which was previously suggested as '*' which would have caused issues
for defining a consistent type for that parameter).
This adds an `allowRevealedAmounts` argument to z_sendmany. This
flag must be present to allow an amount-revealing cross-pool transfer
to be constructed.
This replaces the old implementation of asyncrpcoperation_sendmany
with one where all transaction construction is delegated to the
transaction builder. The capabilities of z_sendmany are somewhat
modified in the process:
* z_sendmany now permits sending funds from a Sprout address to
both transparent and Sapling addresses. PRIVACY NOTE: When
user sends a Sprout->Sapling transaction, the amount of the
transaction is publicly revealed.
* z_sendmany no longer supports transactions sending funds into
the Sprout pool, with the exception of change amounts when
sending from a Sprout address.
* When sending transparent coinbase funds to a set of shielded
addresses, the amount sent to recipients must fully consume
the input value and no change is permitted. This is a slightly
weaker constraint than was previously implemented; in the past,
only a single shielded recipient was allowed.
This adds a new `AddrSet` type for use in note retrieval
as a filter, in place of a heterogeneous list of `RawAddress`
values. `RawAddress` will complicate the handling of addresses
within the wallet after the addition of unified addresses,
because it does not contain transparent receiver types, and
if we retain this polymorphism it means a lot of invalid states
are represented in places we don't want them to be. It's better
to figure out what types of addresses we're working with as soon
as possible after parsing, and use monomorphic calls from there
on in.
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.
Adds HD seed derivation from ZIP-339 mnemonic phrases.
This replaces random generation of transparent spending keys with BIP-44-compatible derivation from a mnemonic seed phrase, and replaces the random HD seed previously used for Sapling HD key derivation
with the same mnemonic seed. After this change, all new transparent and Sapling addresses
will be derived from a new randomly generated mnemonic seed, which is produced in such a way that
it is guaranteed to produce valid unified spending keys at account 0 for all address types.
Closes#5176.
Closes#2673.
After 4.5.2, all wallets will be populated with an emergency
recovery phrase, and all future addresses will be derived from
the associated seed. To prevent potential loss of funds, we
require that the user explicitly invoke the `walletconfirmbackup`
RPC method to verify that they have backed up this seed.
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 ^_^;;
Extend P2P test framework to make it possible to expect reject
codes for transactions and blocks.
(cherry picked from commit bitcoin/bitcoin@20411903d7)
ZIP 239 preparations 2
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#6722
- Only the ancillary commits, not the mempool limiting commits (we have our own).
- bitcoin/bitcoin#6898
- Only the first three commits (we'll cherry-pick the main content later).
- bitcoin/bitcoin#7840
Also remove the RPC deprecation tests for accounts, and make one small
change to another wallet test that relies on account behaviour.
(cherry picked from commit f0dc850bf698f7377797d7d68365d4fc79b0221c)
Previously Bitcoin would send 1/4 of transactions out to all peers
instantly. This causes high overhead because it makes >80% of
INVs size 1. Doing so harms privacy, because it limits the
amount of source obscurity a transaction can receive.
These randomized broadcasts also disobeyed transaction dependencies
and required use of the orphan pool. Because the orphan pool is
so small this leads to poor propagation for dependent transactions.
When the bypass wasn't in effect, transactions were sent in the
order they were received. This avoided creating orphans but
undermines privacy fairly significantly.
This commit:
Eliminates the bypass. The bypass is replaced by halving the
average delay for outbound peers.
Sorts candidate transactions for INV by their topological
depth then by their feerate (then hash); removing the
information leakage and providing priority service to
higher fee transactions.
Limits the amount of transactions sent in a single INV to
7tx/sec (and twice that for outbound); this limits the
harm of low fee transaction floods, gives faster relay
service to higher fee transactions. The 7 sounds lower
than it really is because received advertisements need
not be sent, and because the aggregate rate is multipled
by the number of peers.
(cherry picked from commit f2d3ba73860e875972738d1da1507124d0971ae5)
Zcash: Candidate transactions for INV are not sorted by their
topological depth because we haven't backported bitcoin/bitcoin#6654.
ZIP 239 preparations 1
This is the first of several backports to prepare for ZIP 239. The primary
change is altering `mapRelay` to store `CTransaction`s, which we need
because ZIP 239 requires changing `Inv` messages based on transaction
versions. The other changes are mainly for conflict removal but are also
independently useful.
Backports the following upstream PRs:
- bitcoin/bitcoin#6889
- bitcoin/bitcoin#7125
- bitcoin/bitcoin#7862
- bitcoin/bitcoin#7877
The recent changes to mempool inv logic mean that nodes are much less
likely to immediately return an `inv` message in response to a `mempool`
message. The `p2p_txexpiringsoon` RPC test was relying on the prior
behaviour.
`TestNode.sync_with_ping` now takes an optional `waiting_for` closure
that allows the caller to require that a specific message kind is
received prior to the timeout.
This is the second release in a row where LLVM has cut a X.0.1 for
everything except Darwin, so I've adjusted its URLs and paths on the
assumption this will continue.
Bitcoin Core doesn't actually use tags for managing versions of their
forked dependencies, so we should separately rework this logic for all
of the subtree-managed dependencies. But this at least prevents false
positives.
str4d
Jack Grigg
Kris Nuttycombe
Kris Nuttycombe
sasha
Daira Hopwood
Marshall Gaucher
Steven Smith
Larry Ruane
str4d
ying tong
sasha
zancas
Charlie O'Keefe
Dimitris Apostolou
Larry Ruane
MarcoFalke
Kris Nuttycombe
mdr0id
Wladimir J. van der Laan
Shaul Kfir
Homu
John Newbery
Gregory Maxwell
Pieter Wuille