(provided that the wallet is enabled and pruning is disabled,
and unless `-rescan=0` is specified explicitly).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
In #5809, we attempted to fix the assumption that on startup, the
wallet's best chain was at the same position as the node's chain tip.
This did not account for a condition where the node's block index
might not contain the block corresponding to the wallet's best chain,
because the node had crashed before the block index containing that
block could be written to disk.
This commit adds handling so that the `ThreadNotifyWallets` thread
will not start until the wallet's best block has been restored
to the node's block index and we're able to obtain a pointer to
that state.
This more accurately reflects its meaning, as it corresponds to the most
recently persisted best chain (i.e. the chain tip that the wallet will
return to on restart), rather than the chain tip to which the in-memory
wallet state has been synced.
The previous code assumed that the last chain tip notified to the wallet
was equal to the node's chain tip at startup. However, this assumption
fails if the node shuts down uncleanly, or if a wallet file is moved
from one node to another.
We now try to start notifying from the wallet's best block, and if the
node doesn't have that block we fall back to the node's chain tip like
before.
Closeszcash/zcash#5805.
When a user supplies a unified address as the source of funds
for z_sendmany, the previous behavior could have risked user
privacy by spending transparent UTXOs belonging to different
diversified addresses in the same transaction, thereby linking
those addresses, and consequently any diversified shielded
receivers of unified addresses containing those transparent
receivers.
This change limits selection of transparent UTXOs to only those
explicitly associated with the unified receivers of the provided
source UA. Also, if a UA is provided as the source, the behavior
is maintained that only shielded notes in pools corresponding to
the receivers of that UA will be selected.
The addition of `UnifiedAddress` to the `PaymentAddress` type
introduced the need for methods that interact with payment addresses
to support transparent receivers as shielded ones, which is somewhat
inconsistent with previous uses of the `PaymentAddress` type.
This commit adds both `CKeyID` and `CScriptID` as new variants
of the `PaymentAddress` type. Following commits will shift encoding
and decoding to use the `PaymentAddress` type exclusively wherever
possible, rather than the current mix of `CDestination` and
`PaymentAddress` that complicates the wallet codebase.
The presence of this variant results in a situation where more
of the code than necessary needs to be aware of and handle
decoding failures. This change moves all handling of decoding
failures to the point of decoding.
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.
Move mempool rejections to debug category `mempoolrej`, to make it possible
to show them without enabling the entire category `mempool` which is
high volume.
(cherry picked from commit bitcoin/bitcoin@7f1f8f5edf)
(cherry picked from commit b7b48c8bbdf7a90861610b035d8b0a247ef78c45)
Zcash: Excluding changes to code we haven't backported yet that cause
too many conflicts.
When -blocksonly is set to 1, it interacts with the -walletbroadcast
parameter and sets it to 0 if it has not been set already.This behavior
is not captured by the current documentation, which claims that -blocksonly
does not impact any wallet transactions.
(cherry picked from commit 621e86ee8d0102e2bf41f7656a368083b89b2f83)
Zcash: Excludes max-peer doc changes, since we don't have
block-relay-only peers yet.
Zcash: just a comment fix, no need to blacklist as -whitelistalwaysrelay
will never have been active.
(cherry picked from commit 89d113e02a83617b4e971c160d47551476dacc71)
Also renames whitelistalwaysrelay.
Nodes relay all transactions from whitelisted peers, this
gets in the way of some useful reasons for whitelisting
peers-- for example, bypassing bandwidth limitations.
The purpose of this forced relaying is for specialized gateway
applications where a node is being used as a P2P connection
filter and multiplexer, but where you don't want it getting
in the way of (re-)broadcast.
This change makes it configurable with whitelistforcerelay.
(cherry picked from commit 325c725fb6205e38142914acb9ed1733d8482d46)
Daira Hopwood
Kris Nuttycombe
Kris Nuttycombe
therealyingtong
Jack Grigg
Steven Smith
Pieter Wuille
Larry Ruane
Dimitris Apostolou
Wladimir J. van der Laan
Chun Kuan Lee
Karl-Johan Alm
Homu
glowang
Sjors Provoost
MarcoFalke
str4d
Gregory Maxwell