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)
Zcash: Was "Added -whiteconnections=<n> option" from bitcoin/bitcoin#5288. The
option was later removed in bitcoin/bitcoin#6374 which we merged in #1258. This
commit contains the difference between the two.
Remove bad chain alert partition check
(cherry picked from https://github.com/bitcoin/bitcoin/pull/8275 commit ab8be98fdb25b678a8cd7e89adf06d1b1f6bdd62), original commit message:
As per meeting 2016-03-31
https://bitcoincore.org/en/meetings/2016/03/31/#bad-chain-alerts
The partition checker was producing huge number of false-positives
and was disabled in 0.12.1 on the understanding it would either be
fixed in 0.13 or removed entirely from master if not.
* -maxuploadtarget can be set in MiB
* if <limit> - ( time-left-in-24h-cycle / 600 * MAX_BLOCK_SIZE ) has reach, stop serve blocks older than one week and filtered blocks
* no action if limit has reached, no guarantee that the target will not be surpassed
* add outbound limit informations to rpc getnettotals
Zcash: Also includes a cleanup from bitcoin/bitcoin#5697
As per meeting 2016-03-31
https://bitcoincore.org/en/meetings/2016/03/31/#bad-chain-alerts
The partition checker was producing huge number of false-positives
and was disabled in 0.12.1 on the understanding it would either be
fixed in 0.13 or removed entirely from master if not.
(cherry picked from commit ab8be98fdb25b678a8cd7e89adf06d1b1f6bdd62)