build: Remove Rust staticlib naming workaround
The bug this was working around was fixed in Rust 1.44.0. We now pin
Rust 1.44.1, so we no longer need the workaround (and in fact, it is
necessary to make this change, as rustc no longer generates the old
filename, causing our Windows cross-compile to fail).
The bug this was working around was fixed in Rust 1.44.0. We now pin
Rust 1.44.1, so we no longer need the workaround (and in fact, it is
necessary to make this change, as rustc no longer generates the old
filename).
Some consumers were relying on the libsodium behaviour that the output
length was not checked against the configured hash output length.
blake2b_simd::Hash::as_bytes returns a correctly-sized slice, which we
were then failing to copy into the consumer's buffer. Instead of
requiring the consumer to provide a full-length buffer and then truncate
the output themselves (likely causing a double-copy, as we don't have
nice slices in C++), we instead allow the consumer to consume up to the
maximum output.
Flush witness data when consistent (part 2)
Closes#4680. After CWallet::ChainTipAdded() updates the witness data, it may flush it to disk (SetBestChain()); make sure the locator part is consistent with the witnesses (height).
Make some conversions explicit to reduce sanitizer warnings
The warnings eliminated by this PR are of the forms, for example:
```
src/chain.h:591:16: runtime error: implicit conversion from type 'unsigned long' of value 18446744073709551615 (64-bit, unsigned) to type 'int' changed the value to -1 (32-bit, signed)
src/scalar_4x64_impl.h:130:110: runtime error: implicit conversion from type 'uint64_t' (aka 'unsigned long') of value 533633915002 (64-bit, unsigned) to type 'unsigned char' changed the value to 122 (8-bit, unsigned)
src/zcash/util.cpp:9:25: runtime error: implicit conversion from type 'uint64_t' (aka 'unsigned long') of value 1000000000 (64-bit, unsigned) to type 'std::vector<unsigned char, std::allocator<unsigned char> >::value_type' (aka 'unsigned char') changed the value to 0 (8-bit, unsigned)
```
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Address some performance regressions
@str4d identified and fixed some performance regressions in our elliptic curve and proving crates, and we also changed to complete formulas in `bls12_381` to get some better performance in some cases. The result:
```
v3.1.0
"runningtime": 0.59883
before upgrading rust:
"runningtime": 0.823932
after upgrading rust:
"runningtime": 0.83004
after upgrading rust packages:
"runningtime": 0.763065
```
which gets us some of the way back to where we were.
wallet: Add ANY_TADDR special string to z_sendmany
When using this special string as the from address, non-coinbase UTXOs
from any transparent addresses within the wallet will be used to fund the
transaction. Change outputs will be sent to a new transparent address,
as with any other spend of transparent funds.
Closeszcash/zcash#3640.
depends: Switch to `cargo vendor` for Rust dependencies
When we first integrated Rust into our build system, we had two
limitations:
- We were building the `librustzcash` FFI library as a dependency, and
therefore needed access to its crate dependencies in the depends
system.
- Gitian builds happen offline, so we needed to fetch any crate
dependencies ahead of time, and then configure cargo to use these in
an offline environment.
At the time, `cargo` already had support for "Source Replacement", but
there was no easy way to package the dependencies in the necessary way.
What we implemented was effectively the `cargo-vendor` tool, built using
Makefiles. A noticeable downside was that we were pinning dependencies
twice: once in the `Cargo.lock` for the FFI library, and again in our
depends system.
Since then, `cargo-vendor` has been upstreamed into `cargo` itself, and
we have moved `librustzcash` into this repository. We can therefore use
`cargo vendor` directly from our pinned Rust compiler to fetch the
dependencies, and rely on our local `Cargo.lock` to pin the specific
crates we are relying on.
During Gitian builds, SOURCES_PATH is set to a path within the Gitian
cache. Normally this path is created as part of creating a particular
dependency's source directory, but in some situations we may vendor Rust
crates before this folder exists.
When we first integrated Rust into our build system, we had two
limitations:
- We were building the `librustzcash` FFI library as a dependency, and
therefore needed access to its crate dependencies in the depends
system.
- Gitian builds happen offline, so we needed to fetch any crate
dependencies ahead of time, and then configure cargo to use these in
an offline environment.
At the time, `cargo` already had support for "Source Replacement", but
there was no easy way to package the dependencies in the necessary way.
What we implemented was effectively the `cargo-vendor` tool, built using
Makefiles. A noticeable downside was that we were pinning dependencies
twice: once in the `Cargo.lock` for the FFI library, and again in our
depends system.
Since then, `cargo-vendor` has been upstreamed into `cargo` itself, and
we have moved `librustzcash` into this repository. We can therefore use
`cargo vendor` directly from our pinned Rust compiler to fetch the
dependencies, and rely on our local `Cargo.lock` to pin the specific
crates we are relying on.
Allow multiple nuparams options in config file
We didn't add this in zcash/zcash#4583 because `-nuparams` is only ever
used as a CLI argument in our testing infrastructure. It turns out that
there are external developers using regtest mode with `nuparams` in
their config files instead. Neat!
Closeszcash/zcash#4705.
After CWallet::ChainTipAdded() updates the witness data, it
may flush it to disk (SetBestChain()); make sure the locator
part is consistent with the witnesses (height).
We didn't add this in zcash/zcash#4583 because `-nuparams` is only ever
used as a CLI argument in our testing infrastructure. It turns out that
there are external developers using regtest mode with `nuparams` in
their config files instead. Neat!
Closeszcash/zcash#4705.
add shielded balance to getwalletinfo
Closeszcash/zcash#3939
It is based on the definition that unconfirmed balance has 0 confirmations; anything else is regular balance.
Implementation:
1. `getBalanceZaddr` uses one version of `GetFilteredNotes`, we want to use the other version that allow us to get balances inside min and max confirmations.
2. `shielded_unconfirmed_balance`, and `shielded_balance` are obtained by calling `getBalanceZaddr` with different min and max confirmations according to the definitions from above.
Prevent creation of shielded transactions when chain is not synced up
Part of zcash/zcash#3996.
Inspired by jl777/komodo#1486 and jl777/komodo#1493, but takes a different approach:
- Uses a function `ThrowIfInitialBlockDownload()` that checks `IsInitialBlockDownload()`, instead of macros.
- Added `initial_block_download_complete` output only to `getblockchaininfo`.