Enabled ShellCheck rules:
SC1087
SC2001
SC2004
SC2005
SC2006
SC2016
SC2028
SC2048
SC2066 (note that IFS already contains only a line feed)
SC2116
SC2166
SC2181
SC2206
SC2207
SC2230
SC2236
(cherry picked from commit bitcoin/bitcoin@1ac454a384)
Zcash: Applies more of this commit. It was partially backported in
zcash/zcash#4827, and is also partially backported here for the scripts
we actually have.
Putting the build date in the executable is a practice that has no place
in these days, now that deterministic building is increasingly common.
Continues #7732 which did this for the GUI.
(cherry picked from commit bitcoin/bitcoin@d096d22446)
Changes the error message from:
./autogen.sh: 9: ./autogen.sh: autoreconf: not found
To:
configuration failed, please install autoconf first
(cherry picked from commit bitcoin/bitcoin@889426d37e)
Many error messages would say "see debug.log" or similar, without
indicating where the debug log actually lives. This now prints the
actual path in those cases.
It also changes more general uses of "debug.log" to "debug log", since
the file name may not even be "debug.log" if the user has specified it.
The primary purpose of this commit is an exercise in using `cargo vet`
for tracking audits of our Rust dependency updates. `cargo update` was
run, and then a simple-to-audit subset of the dependency updates were
audited and committed.
In practice we are using 14.0.0 in most cases, as the LLVM Project have
not published Ubuntu binaries for any point release after 14.0.0 (which
we are using here).
Previously when a transaction was queried for batch trial decryption, we
identified it by its txid. This is sufficient to uniquely identify the
transaction within the wallet, but was _not_ sufficient to uniquely
identify it within a `ThreadNotifyWallets` loop. In particular, when a
reorg occurs, and the same transaction is present in blocks on both
sides of the reorg (or is reorged into the mempool and then conflicted
out):
- The first occurrence would batch the transaction's outputs and store a
result receiver.
- The second occurrence would overwrite the first occurrence's result
receiver with its own.
- The first occurrence would read the second's result receiver (which
has identical results to the first batch), removing it from the
`pending_results` map.
- The second occurrence would not find any receiver in the map, and
would mark the transaction as having no decrypted results.
We fix this by annotating each batched transaction with the hash of the
block that triggered it being trial-decrypted: either the block being
disconnected, the block being connected, or the null hash to indicate
a new transaction in the mempool. This is sufficient to domain-separate
all possible sources of duplicate txids:
- If a transaction is moved to the mempool via a block disconnection, or
from the mempool (either mined or conflicted) via a block connection,
its txid will appear twice: once with the block in question's hash,
and once with the null hash.
- If a transaction is present in both a disconnected and a connected
block (mined on both sides of the fork), its txid will appear twice:
once each with the two block's txids.
Both of the above rely on the assumption that block hashes are collision
resistant, which in turn relies on SHA-256 being collision resistant.
Hennadii Stepanov
MarcoFalke
Luke Dashjr
James White
Wladimir J. van der Laan
Andrés G. Aragoneses
str4d
Jack Grigg
Kris Nuttycombe
Greg Pfeil
ebfull
Daira Hopwood
sasha