* Introduce new constant MIN_CHANGE and use it instead of the
hardcoded "CENT"
* Add test case for MIN_CHANGE
* Introduce new constant for -mintxfee default:
DEFAULT_TRANSACTION_MINFEE = 1000
Bitcoin script PRs 1
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#6335
- bitcoin/bitcoin#6424
- bitcoin/bitcoin#11058
- bitcoin/bitcoin#12460
- bitcoin/bitcoin#13194
Part of #2074.
This reverts commit 734e594c2c.
It appears that this was fixing a single issue with the FreeBSD build,
while b6d0996cec addressed the underlying
cause. However, the change in this commit overrides the underlying fix
when cross-compiling for Darwin.
The build environment is applied to the entire configured build_cmds
section, but it doesn't carry over past the && between the gmock and
gtest builds. This causes problems when cross-compiling for darwin, as
the correctly-configured clang++ is provided in the build environment.
This sidesteps the problem where the atomics check tries to run a test
binary, which cannot be performed during cross compilation. We should
replace this with a better solution in future.
Part of #3710.
Some dependency sources were downloaded via http, even though https (SSL/TLS) options are available.
Even if we potentially check the integrity of the downloaded files via hash comparison, we should make
use of this additional security layer.
Zcash:
native_cctools.mk
For normal users, --no-same-owner is default, but not so for root, where
it is assumed that root can change ownership willy-nilly. This is not
the case for privilege-limited container environments where we gaslight
the process into thinking it's root.
Zcash: Excludes QT changes
ld64 is threaded, and uses a worker for each CPU to parse input files. But
there's a bug in the parser causing dependencies to be calculated differently
based on which files have already been parsed.
As a result, builders with more CPUs are more likely to see non-determinism.
This looks to have been fixed in a newer version of ld64, so just disable
threading for now. There's no noticible slowdown.
clang: 3.7.1
cctools: 877.8
ld64: 253.9
Zcash: Second part of f25209a3e1e6488d4d44de15b0f113d2302e9aee from
upstream (we merged the first part in #2697).
Change "protect" terminology to "shield"
Closes https://github.com/zcash/zcash/issues/2149
Note: Renamed `wallet_protectcoinbase.py` to `wallet_shieldingcoinbase.py` because there was an existing file also named `wallet_shieldcoinbase.py`.
The current code contains a rather complex script template matching engine,
which is only used for 3 particular script types (P2PK, P2PKH, multisig).
The first two of these are trivial to match for otherwise, and a specialized
matcher for multisig is both more compact and more efficient than a generic
one.
The goal is being more flexible, so that for example larger standard multisigs
inside SegWit outputs are more easy to implement.
As a side-effect, it also gets rid of the pseudo opcodes hack.
Previously this was an inline test where the specificity was probably judged
overly specific. As a class method it makes sense to maintain consistency.
And replace some magic values with their constant equivalents.
Zcash: Excludes changes to the following functions we don't have:
- ExtractPubKey (bitcoin/bitcoin#6415)
- IsCompressedPubKey (bitcoin/bitcoin#8499)
Previously only one PUSHDATA was allowed, needlessly limiting
applications such as matching OP_RETURN contents with bloom filters that
operate on a per-PUSHDATA level. Now any combination that passes
IsPushOnly() is allowed, so long as the total size of the scriptPubKey
is less than 42 bytes. (unchanged modulo non-minimal PUSHDATA encodings)
Also, this fixes the odd bug where previously the PUSHDATA could be
replaced by any single opcode, even sigops consuming opcodes such as
CHECKMULTISIG. (20 sigops!)
Previously unlike other transaction types the TX_SCRIPTHASH would not
clear vSolutionsRet, which means that unlike other transaction types if
it was called twice in a row you would get the result of the previous
invocation as well.
We always locally check alerts against our subversion string without comments.
This change ensures that we will also propagate alerts to peers based on their
subversion strings without comments. Note that if an alert specifically targets
a commented subversion string, we will only relay it to peers with the exact
same comments.