The Rust parser is stricter than the C++ parser, so we can reach errors
now non-contextually that previously were thrown by the consensus rules.
Various tests have been updated to check for these exceptions, as they
can no longer instantiate these transactions to pass to the consensus
rules. The tests use an unsafe constructor so they can still check the
consensus rules.
The C++ parser only requires the various Sapling components to be 32-byte
arrays. The Rust parser enforces stricter type checks at parse time, and
we now unconditionally parse with the Rust parser for deriving txids.
The majority of the parser is in C++, but Orchard bundles are parsed
exclusively by Rust.
The ZIP 244 test vectors are brought in here so we can start by testing
round-trip serialization.
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
(cherry picked from commit 69ffddc83e0f3e265bf6cf7ae31489ae629fe6be)
Zcash: Excluding change to src/test/fuzz/bloom_filter.cpp which we
don't have (we haven't backported upstream's fuzzing framework).
On msvc14, int literal '-2147483648' is invalid, because '2147483648' is unsigned type and cant't apply minus operator to unsigned type.
To define the int literal correctly, use '-2147483647 - 1' formula that is also used to define INT_MIN in limits.h.
(cherry picked from commit 8e0720bdb9141b00b4c00893b8139904c67ddacf)
Output instances of "BloomFilter" changed to "Bloom filter", in accordance with Wikipedia standard notation:
https://en.wikipedia.org/wiki/Bloom_filter
also to sync with the majority of cases in the self-same file
(cherry picked from commit b7aa2902fd3c29487f585c264d8845899f4c1846)
This patch changes the implementation from one that stores 16 2-bit integers
in one uint32_t's, to one that stores the first bit of 64 2-bit integers in
one uint64_t and the second bit in another. This allows for 450x faster
refreshing and 2.2x faster average speed.
(cherry picked from commit 1953c40aa9589a03035fd294f3ba3549374a4826)
test: Convert Bech32 test vectors into known-answer test vectors
This enables other projects to confirm independently that their encoding
or decoding functions are consistent, instead of merely that they are
round-trip correct.
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.
- add a swap operation to prevector tests (fails due to broken prevector::swap)
- fix 2 prevector test operation conditions that were impossible
(cherry picked from commit 4ed41a2b611dfd328fe6f72312d6c596650f03f8)
banlist.dat: store banlist on disk
Cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#6310
- bitcoin/bitcoin#6315
- Only the new signal and net changes, no QT.
- bitcoin/bitcoin#7350
- bitcoin/bitcoin#7458
- bitcoin/bitcoin#7696
- bitcoin/bitcoin#7959
- bitcoin/bitcoin#7906
- Only the ban-related commits.
- bitcoin/bitcoin#8392
- Only the second commit.
- bitcoin/bitcoin#8085
- Only the second commit.
- bitcoin/bitcoin#10564
- bitcoin/bitcoin#13061
- Wasn't needed when I first made this backport in 2017, but it is now!
Part of #2074.
* CAddrDB modified so that when de-serialization code throws an exception Addrman is reset to a clean state
* CAddrDB modified to make unit tests possible
* Regression test created to ensure bug is fixed
* StartNode modifed to clear adrman if CAddrDB::Read returns an error code.
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)
This enables other projects to confirm independently that their encoding
or decoding functions are consistent, instead of merely that they are
round-trip correct.
We didn't initially expose these because we assumed that this API was
likely being used somewhere in the ecosystem. However, the build system
for libzcashconsensus has been broken since 2018, and no issues were
raised, which strongly indicates that this API is not currently in use.
This removes the last implicit dependency on libsodium from
libzcashconsensus.
As of zcash/zcash#4893 we no longer depend on libsodium for Ed25519
signature verification.
This matches the existing transaction builder structs:
- SpendDescriptionInfo
- OutputDescriptionInfo
- TransparentInputInfo
It also removes the dependency of the transaction format on the proving
system.
Partial revert of "Update links"
This partially reverts commit f459e43dc9. See #4904.
In summary, the rationale is that:
* Some of the changed files are from subtrees, which should be updated upstream.
* The licensing of four of the files under `build-aux/m4` is complicated and so changes to them should have required review with that in mind: 5b97cd27f8/COPYING (L38-L44)
* The changes to `contrib/debian/copyright` must also be reverted because those are in copies of specific versioned licenses.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
- Use the python standard logging library
- Run all tests and report all failing test-cases (rather than stop after one test case fails)
- If output is different from expected output, log a contextual diff.
This splits the output comparison for `bitcoin-tx` into two steps:
- First, check for data mismatch, parsing the data as json or hex
depending on the extension of the output file
- Then, check if the literal string matches
For either of these cases give a different error.
This prevents wild goose chases when e.g. a trailing space doesn't match
exactly, and makes sure that both test output and examples are valid
data of the purported format.
Improve reject reasons for unmet shielded requirements
These reject messages end up bubbling up to users via the RPC interface.
Distinguishing between the various failure cases will help users figure
out why their transaction is being rejected.
Closeszcash/zcash#3114.
This change unifies handling of the -ibdskiptxverification
flag and ensures consistent handling of checkpoint heights
when evaluating whether transaction verification may be skipped.
This change also removes two redundant CheckBlock calls. This
change is consensus-critical and requires 3 reviews.
- The old patch is no longer necessary because of this upstream fix:
https://github.com/boostorg/build/pull/560
- Boost 1.72 removed a <deque> from an include, which exposed a missing
include in src/httpserver.cpp.
- Boost 1.73 moved function placeholders into the boost::placeholders
namespace.
- The new patch is a fix from just after Boost 1.74 was released, fixing
a warning that was missed.
A few "a->an" and "an->a".
"Shows, if the supplied default SOCKS5 proxy" -> "Shows if the supplied default SOCKS5 proxy". Change made on 3 occurrences.
"without fully understanding the ramification of a command" -> "without fully understanding the ramifications of a command".
Removed duplicate words such as "the the".
Zcash: Only the changes to files and code that we have.
crypto_sign_verify_detached is still used within the consensus rules
until Canopy activation. ed25519-zebra generates signatures that are
valid under both pre- and post-Canopy rules (for our honest usage),
so we can use it to generate transaction signatures now. Then once
Canopy activates, we can remove the remaining usages of crypto_sign.
Refactor ProofVerifier
`ProofVerifier` was previously used to conditionally verify pre-Sapling Sprout
proofs (based on `ProofVerifier::Strict` or `ProofVerifier::Disabled` being
used), but hybrid Sprout proofs bypassed it (so were being verified multiple
times during block verification), and once `libsnark` was removed in
zcash/zcash#4060 `ProofVerifier::check` was doing nothing.
This PR refactors `ProofVerifier`, moving it out of the `libzcash` compilation
unit (so that it can depend on `primitives/transaction.h`), and moving Sprout
verification from `JSDescription::Verify` to `ProofVerifier::VerifySprout`.
Verification-skipping for Sprout proofs is re-introduced.
Additionally, the `ZCJoinSplit` global is removed from the codebase, and
`ZCJoinSplit::prove` is converted into a static function. We load the hybrid
Sprout parameters dynamically at proving time within the Rust code, and no
longer require a C++ global for any proving parameters.
As a side-effect, `libzcashconsensus.la` building with `--with-libs` is fixed,
as `primitives/transaction.cpp` no longer depends on `librustzcash.h`.
Add a pool for locked memory chunks, replacing LockedPageManager.
This is something I've been wanting to do for a long time. The current
approach of locking objects where they happen to be on the stack or heap
in-place causes a lot of mlock/munlock system call overhead, slowing
down any handling of keys.
Also locked memory is a limited resource on many operating systems (and
using a lot of it bogs down the system), so the previous approach of
locking every page that may contain any key information (but also other
information) is wasteful.
It needs to be closer to the root of our dependency tree, so that it can
depend on the transaction format. The libzcash compilation unit is
further from the dependency tree root than the transaction format.
We don't support making pre-Sapling JoinSplit proofs, and we load the
parameters for post-Sapling JoinSplit proofs at proving time, so there
is no need for a global ZCJoinSplit to be passed through the APIs.
Fix advertised version
Closes https://github.com/zcash/zcash/issues/4375 by adding the `-` character to the list of safe ones.
Now i can see stuff like the following in the logs:
```
...
2020-04-13 14:19:37 receive version message: /MagicBean:2.1.1-1/: version 170009, blocks=795400, us=[2800:a4:316b:8e00:ceb:c7b4:3481:197f]:59754, peer=2
...
```
API call `getpeerinfo` will also gets fixed.
CBlockHeader.hashFinalSaplingRoot has been renamed to hashLightClient.
CBlockIndex now stores:
- hashLightClient as from the block header
- hashFinalSaplingRoot, which is accurate for all blocks prior to
Heartwood activation, and all blocks from Heartwood activation onward
that are connected at some point to the main chain in ConnectBlock().
- hashChainHistoryRoot, which is null prior to Heartwood activation, and
set per ZIP 221 from Heartwood activation.
The new block index fields are only written to disk for client version
2.1.2 and above, which will be the first Heartwood-aware clients (even
if Heartwood doesn't have an activation height).
Refactor experimental feature handling
Adds new rpc call `getexperimentalfeatures` and also adds experimental features to `getblockchaininfo` output.
Closes#2671.
Remove time adjustment; instead warn if peer clocks are too different
The policy is: warn if we have seen at least 8 (TIMEDATA_WARNING_SAMPLES) peer times, in the version messages of the first 20 (TIMEDATA_MAX_SAMPLES) unique (by IP address) peers that connect, that are more than 10 minutes (TIMEDATA_WARNING_THRESHOLD seconds) but less than 10 days (TIMEDATA_IGNORE_THRESHOLD seconds) away from local time.
fixes#4338
This moves all access to these datastructures through accessor functions
and protects them with a lock.
Relative to the upstream commit, we also add GetMiscWarning() to make this accessible to tests.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
There are only a few uses of `insecure_random` outside the tests.
This PR replaces uses of insecure_random (and its accompanying global
state) in the core code with an FastRandomContext that is automatically
seeded on creation.
This is meant to be used for inner loops. The FastRandomContext
can be in the outer scope, or the class itself, then rand32() is used
inside the loop. Useful e.g. for pushing addresses in CNode or the fee
rounding, or randomization for coin selection.
As a context is created per purpose, thus it gets rid of
cross-thread unprotected shared usage of a single set of globals, this
should also get rid of the potential race conditions.
- I'd say TxMempool::check is not called enough to warrant using a special
fast random context, this is switched to GetRand() (open for
discussion...)
- The use of `insecure_rand` in ConnectThroughProxy has been replaced by
an atomic integer counter. The only goal here is to have a different
credentials pair for each connection to go on a different Tor circuit,
it does not need to be random nor unpredictable.
- To avoid having a FastRandomContext on every CNode, the context is
passed into PushAddress as appropriate.
There remains an insecure_random for test usage in `test_random.h`.
Zcash: Resolved conflicts with the following files
src/addrman.cpp
src/main.cpp
src/net.cpp
src/net.h
src/policy/fees.cpp
src/policy/fees.h
src/random.cpp
src/test/merkle_tests.cpp
src/test/net_tests.cpp
src/test/prevector_tests.cpp
src/test/sighash_tests.cpp
src/test/skiplist_tests.cpp
src/test/test_bitcoin.cpp
src/test/versionbits_tests.cpp
src/wallet/test/crypto_tests.cpp
Such outputs can still be watched, and signed for, but they aren't treated as valid payments.
That means they won't cause transactions to appear in listtransactions, their outputs to be
shown under listunspent, or affect balances.
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.
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!)
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.
`bitcoind -X -noX` ends up, unintuitively, with `X` set.
(for all boolean options X)
This result is due to the odd two-pass processing of arguments. This
patch fixes this oddity and simplifies the code at the same time.
As suggested by Greg Maxwell-- unit test to make sure a block
with a double-spend in it doesn't pass validation if half of
the double-spend is already in the memory pool (so full-blown
transaction validation is skipped) when the block is received.
Use CommitTransaction
This enables `-walletbroadcast` to correctly control transactions created with `z_*` APIs. It also addresses some TODOs in the code and consolidates some repeated logic.
Closes#4077 (because `CommitTransaction` calls `KeepKey` on the transparent change address).
Jack Grigg
Homu
Jeremy Rubin
Sebastian Falbesoner
kobake
S. Matthew English
Pavel Janík
Pieter Wuille
Gregory Maxwell
Casey Rodarmor
Kaz Wesley
Wladimir J. van der Laan
Bernhard M. Wiedemann
EthanHeilman
Jonas Schnelli
BtcDrak
Daira Hopwood
Kris Nuttycombe
Dimitris Apostolou
MarcoFalke
Jorge Timón
John Newbery
Mustafa
Nick
str4d
Dimitris Tsapakidis
Taylor Hornby
Cory Fields
Alfredo Garcia
NikVolf
Larry Ruane
mdr0id
Jim Posen
Jonas Schnelli
Peter Todd
Luke Dashjr
Gavin Andresen
Dagur Valberg Johannsson
Eirik Ogilvie-Wigley
Sean Bowe