0a433fc876d82df1005f175c1254fff62f0f36f8 [validation] Remove unused cacheSigStore from CheckInputsFromMempoolAndCache (John Newbery)
Pull request description:
CheckInputsFromMempoolAndCache() is only called in one place, and
cacheSigStore is set to true in that call site. Remove the argument
entirely.
Also improve commenting.
ACKs for top commit:
MarcoFalke:
unsigned ACK 0a433fc876d82df1005f175c1254fff62f0f36f8 Comment looks good
jamesob:
ACK 0a433fc876
laanwj:
ACK 0a433fc876d82df1005f175c1254fff62f0f36f8
fanquake:
ACK 0a433fc876d82df1005f175c1254fff62f0f36f8. Checked that `CheckInputsFromMempoolAndCache` is only called once, in `MemPoolAccept::ConsensusScriptChecks`, and that `cacheSigStore` is true.
Tree-SHA512: e4b4d2550e35df55c8f8fa4c539174cc2d3728112ddb937cb2ff759d8630a01566b5ec42a70a82e33994e6586f5a457a75a59f64b15d27c65331c723cbb097af
fa928134075220254a15107c1d9702f4e66271f8 consensus: Explain why fCheckDuplicateInputs can not be skipped and remove it (MarcoFalke)
Pull request description:
As a follow up to CVE-2018-17144, this removes the unused `fCheckDuplicateInputs` parameter and explains why the test can not be disabled. Apart from protecting against a dumb accident in the future, this should document the logic in the code. There is a technical write-up that explains how the underlying coins database behaves if this test is skipped: https://bitcoincore.org/en/2018/09/20/notice/#technical-details. However, it does not explicitly mention why the test can not be skipped. I hope my code comment does that.
ACKs for top commit:
jnewbery:
ACK fa928134075220254a15107c1d9702f4e66271f8
amitiuttarwar:
utACK fa928134075220254a15107c1d9702f4e66271f8
Empact:
Code review ACK fa92813407
promag:
ACK fa928134075220254a15107c1d9702f4e66271f8.
Tree-SHA512: fc1ef670f1a467c543b84f704b9bd8cc7a59a9f707be048bd9b4e85fe70830702aa560a880efa2c840bb43818ab44dfdc611104df04db2ddc14ff92f46bfb28e
07cae5287c [wallet] remove unused GetScriptForMining (Sjors Provoost)
8bb3e4c487 [rpc] remove deprecated generate method (Sjors Provoost)
Pull request description:
As announced in v0.18, the wallet generate rpc method is deprecated and will be fully removed in v0.19.
Clients should transition to using the node rpc method `generatetoaddress`.
Tree-SHA512: 9e5e913b59f3e18440b2b7b356124c7b87ad19f81a1ab6ada06a6c396b84e734895465f569296f1ba8c12abf74863bab5fd77765c9e806c239713aa83a59485f
* wallet: Use temporary structure to update metadata correctly while generating new hd keys
* wallet: Make sure to never update an already existing key_origin while deriving hd keys
0da49b5 Skip precompute sighash for transactions without witness (Johnson Lau)
Pull request description:
This saves unnecessary hash caching for non-segwit transactions, but I am not sure if the difference is noticeable.
Tree-SHA512: 5cd733a729a52a45781510b3572b26e76837a94155caa14311c6d23a27a12e9613ff278dfc2592e21f640202782f22c5ad00fca85c4de5efacaa617c48ccb08d
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
e9440aeb5cad98fea9971f5126461e0a2b30ab54 build: use __SIZEOF_INT128__ for checking __int128 availability (fanquake)
Pull request description:
We already use this in the blockfilter code,
bf66e258a8/src/blockfilter.cpp (L34-L36)
so not sure we need to maintain two different ways of testing
for the same functionality. Consolidate on testing for `__SIZEOF_INT128__`,
which we already use, is supported by the compilers we care about, and is
also used by libsecp256k1.
ACKs for top commit:
sipa:
utACK e9440aeb5cad98fea9971f5126461e0a2b30ab54
Zero-1729:
crACK e9440aeb5cad98fea9971f5126461e0a2b30ab54
Tree-SHA512: 8aeef1734486a863b5091123bb5f9ba8868b1e2b4b35114586e3eb5862a38d4a1518ed069f37f41cb5e5ce2f6c87d95671996366d5ee990e0c90f268a8978ba3
8f7b93047581c67f2133cdb8c7845471de66c30f Drop the leading 0 from the version number (Andrew Chow)
Pull request description:
Removes the leading 0 from the version number. The minor version, which we had been using as the major version, is now the major version. The revision, which we had been using as the minor version, is now the minor version. The revision number is dropped. The build number is promoted to being part of the version number. This also avoids issues where it was accidentally not included in the version number.
The CLIENT_VERSION remains the same format as previous as previously, as the Major version was 0 so it never actually got included in it.
The user agent string formatter is updated to follow this new versioning.
***
Honestly I'm just tired of all of the people asking for "1.0" that maybe this'll shut them up. Skip the whole 1.0 thing and go straight to version 22.0!
Also, this means that the terminology we commonly use lines up with how the variables are named. So major versions are actually bumping the major version number, etc.
ACKs for top commit:
jnewbery:
Code review ACK 8f7b930475
MarcoFalke:
review ACK 8f7b93047581c67f2133cdb8c7845471de66c30f 🎻
Tree-SHA512: b5c3fae14d4c0a9c0ab3b1db7c949ecc0ac3537646306b13d98dd0efc17c489cdd16d43f0a24aaa28e9c4a92ea360500e05480a335b03f9fb308010cdd93a436
3ed8e3d079a3860dcdf944f7c1aa37765a53da32 doc: Remove explicit network name references (Fabian Jahr)
d6e493f0c2850b522a676a005935163beddaa2cc wallet: Remove left-over BIP70 comment (Fabian Jahr)
Pull request description:
A small follow-up to #17165 which removed BIP70 support.
1. Removes one leftover mention of BIP70 in a comment.
2. Removes BIP70 reference in comments on network/chain name strings. These can be removed as they are not really helpful and also incorrect: BIP70 only defines "main" and "test" but not "regtest". If/When signet gets merged we will add another name to the list that is not defined in BIP70. Mostly there is also an exhaustive list of the options included in the comment anyway.
If we would like to keep an identifier for this naming scheme, I would suggest switching to something more generic, like 'short chain name'. Happy to implement that if that is preferred. Alternatively, we could add a reference to `CBaseChainParams`. That would also mean we don't have to change these lines again for signet.
ACKs for top commit:
MarcoFalke:
ACK 3ed8e3d079a3860dcdf944f7c1aa37765a53da32
Tree-SHA512: 9a7c0b9cacbb67bd31a089ffdc6f1ebc7f336493e2c8266eb697da34dce2b505a431d5639a3e4fc34f9287361343e861b55dc2662e0a1d2095cc1046db77d6ee
Issues with current implementation: params list is not mentioning `baseBlockHashes`, `baseBlockHashesNb` looks excessive, no default values, handling of baseBlockHash-es is off by 1 (`3 + i` should be `4 + i`).
before:
```
> help quorum rotationinfo
quorum rotationinfo "blockRequestHash" baseBlockHashesNb extraShare
Get quorum rotation information
Arguments:
1. blockRequestHash (string, required) The blockHash of the request.
2. baseBlockHashesNb (numeric, required) Number of baseBlockHashes
3. extraShare (boolean, required) Extra share
```
after:
```
> help quorum rotationinfo
quorum rotationinfo "blockRequestHash" ( extraShare "baseBlockHash..." )
Get quorum rotation information
Arguments:
1. blockRequestHash (string, required) The blockHash of the request.
2. extraShare (boolean, optional, default=false) Extra share
3. baseBlockHash... (string, optional, default=) baseBlockHashes
```
84547fa6d408bdda1685f6d5972232bb19d97a7d Avoid creating a temporary vector for size-prefixed elements (Pieter Wuille)
Pull request description:
This is a simple improvement to the PSBT serialization code, avoiding the need for temporary vectors everywhere.
Tree-SHA512: 9f7243b7169ec8ba00ffad31af03c016ab84e4f76ebac810167f91f5e8008f3827ad59fbcee0cb2bd2334fc26466eb222404af24e7fb6ec040fd78229ebe0fd1
* Edge case fix
* Simpler syntax
* add a bit of documentation, and adjust scopes
* use a switch statment
* adjust how returning happens
Co-authored-by: pasta <pasta@dashboost.org>
fad140e311028f904635126e3c77352afac1b75e test: Set correct nValue for multi-op-return policy check (MarcoFalke)
Pull request description:
`CTxOut::nValue` is default-initialized to `-1`. The dust-threshold for `OP_RETURN` outputs is `0`. Thus, the policy failure would be `dust` instead of `multi-op-return`. The test only passes because the dust check is currently not run.
Avoid that confusion by setting the value to `0`, to ensure the dust check passes.
ACKs for top commit:
theStack:
ACK fad140e311028f904635126e3c77352afac1b75e
Tree-SHA512: f0c7a68eb2c573d6595b2b129fa8fa2a34fa35c17691f448bf1c54ccf66059c37562e7480cde7b51c4de677038d7717873da4257147a5f60acc8bbcd25fb7e3f
e95aaefe2540cb76969818fcc2ff77d33448ed5a build: Avoid secp256k1.h include from system (Niklas Gögge)
Pull request description:
While building i ran into an error because i had a version of `secp256k1.h` under `/usr/local/include` that was incompatible with the secp256k1 code in the repository. This caused a problem because `$(BOOST_CPPFLAGS)` contained `-I/usr/local/include` and the include paths are searched by the compiler in order from left to right, so in the end `$(BITCOIN_INCLUDES)` contained `-I/usr/local/include` before `-I$(srcdir)/secp256k1/include` which caused the compiler to find `secp256k1.h` under `/usr/local/include`.
Looking at git blame i am wondering how this has not happened to anyone else in several years: cb89e18845/src/Makefile.am (L25)
I am on macOS 10.15.
ACKs for top commit:
laanwj:
Code review ACK e95aaefe2540cb76969818fcc2ff77d33448ed5a
hebasto:
ACK e95aaefe2540cb76969818fcc2ff77d33448ed5a, tested on macOS 11 Big Sur by adding `#error` into `/usr/local/include/secp256k1.h`.
Tree-SHA512: 1f0b395725936c179ab60dee3582ec7b21e2f9c0f1895e160d84a487cf0db16d0c7aa47d05800e0aded31685b4362056cac9b9ecca1bb8c308a4c5a810e8dc1d
330cb33985d0ce97c20f4a0f0bbda0fbffe098d4 src/randomenv.cpp: fix build on uclibc (Fabrice Fontaine)
Pull request description:
Check for HAVE_STRONG_GETAUXVAL or HAVE_WEAK_GETAUXVAL before using
getauxval to avoid a build failure on uclibc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
ACKs for top commit:
laanwj:
Code review ACK 330cb33985d0ce97c20f4a0f0bbda0fbffe098d4
Tree-SHA512: 94fbbdb0e859f0220d64b2d04565f575b410327f080125fec7fb74205d0bea0e8133561c83a696033d6dc377871133871b72c1aad19aca61e972ce67e0fdf707
bd5215103eb3985c1622eddea45a040e6173829c random: fixes read buffer resizing in RandAddSeedPerfmon (Ethan Heilman)
Pull request description:
As shown below when resizing the read buffer `vData` `std::max((vData.size() * 3) / 2, nMaxSize)` is used. This means that the buffer size immediately jumps to `nMaxSize`. I believe the intend of this code is to grow the buffer size through several steps rather than immediately resize it to the max size.
```cpp
std::vector<unsigned char> vData(250000, 0);
long ret = 0;
unsigned long nSize = 0;
const size_t nMaxSize = 10000000; // Bail out at more than 10MB of performance data
while (true) {
nSize = vData.size();
ret = RegQueryValueExA(HKEY_PERFORMANCE_DATA, "Global", nullptr, nullptr, vData.data(), &nSize);
if (ret != ERROR_MORE_DATA || vData.size() >= nMaxSize)
break;
vData.resize(std::max((vData.size() * 3) / 2, nMaxSize)); // Grow size of buffer exponentially
}
```
vData always starts at size 250,000 and nMaxSize is always 10,000,000 so the first time this line is reached:
```cpp
vData.resize(std::max((vData.size() * 3) / 2, nMaxSize));
```
the effect will always be to resize vData to nMaxSize. Then because the loop terminates when vData.size >= 10,000,000 only one resize operation will take place.
To fix this issue we replace `std::min` with `std::max`
This PR also adds a comment clarifying the behavior of this function the first time it is called.
ACKs for top commit:
fanquake:
ACK bd5215103eb3985c1622eddea45a040e6173829c - thanks for taking a look at this Ethan. Swapping from `std::max` to `std::min` here certainly seems correct.
Tree-SHA512: 7c65f700e5bbe44bc2f1ffdcdc99ec19c542894c95b5ee9791facd09d02afae88d1f8f35af129719e4860db94bc790856e7adb1d218a395381e7c2913b95f1d0
e90e3e684ffa7b25f0dfb5b45e70bb0c358261fb build: fix sysctl() detection on macOS (fanquake)
Pull request description:
[`sysctl()` on *BSD](https://www.unix.com/man-page/FreeBSD/3/sysctl/) takes a "const int *name", whereas [`sysctl()` on macOS](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html)
it takes an "int *name". So our configure check and `sysctl()` detection on
macOS currently fails:
```bash
/usr/include/sys/sysctl.h:759:9: note: candidate function not viable:
no known conversion from 'const int [2]' to 'int *' for 1st argument
int sysctl(int *, u_int, void *, size_t *, void *, size_t);
```
The simplest change seems to be to change the param to a "int *name", which
will work during configure on macOS and *BSD systems.
For consistency I've changed both calls, but note that macOS doesn't
have `KERN_ARND`, so that check will always fail regardless. We can revert/add
documentation if preferred.
ACKs for top commit:
laanwj:
Re-ACK e90e3e684ffa7b25f0dfb5b45e70bb0c358261fb
Tree-SHA512: 29e9348136fc72882f63079bf10d2490e845d7656aae2c003e282bea49dd2778204a7776a67086bd88c2852af9a07dd04ba358eede7e37029e1c10f73c85d6a5
d36146009fb3fc9b9a772823b4df139a85173481 Drop unused mach time headers (Ben Woosley)
Pull request description:
Now that we're no longer special-casing clock usage for MacOS (see #17800), we're
not referencing anything defined in these headers.
Incidentally, this removes our last reference to the `__MACH__` system def. 🎉
ACKs for top commit:
jonasschnelli:
utACK d36146009fb3fc9b9a772823b4df139a85173481
fanquake:
ACK d36146009fb3fc9b9a772823b4df139a85173481 - thanks.
Tree-SHA512: 246045b0683a705ad034416e8ace2024e652026a6c0517b6797320e52fc18a6e111ec2e405ca40653bd1d6421bb7755232e8fec22651fff8e448eb7d5646a954
dc9305b6162ec615ff5fb2876e4f312051b543af random: don't special case clock usage on macOS (fanquake)
Pull request description:
`clock_gettime()`, `CLOCK_MONOTONIC` and `CLOCK_REALTIME` are all available for use on
macOS (now that we require macOS >=10.12 and build against 10.14). Use them rather than the [deprecated](https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html) `mach_timespec_t` time API.
I mentioned the possibility for this change [in #17270](https://github.com/bitcoin/bitcoin/pull/17270#discussion_r346090606).
[master](1dbf3350c683f93d7fc9b861400724f6fd2b2f1d):
```bash
2019-12-23T20:49:43Z Feeding 216 bytes of dynamic environment data into RNG
2019-12-23T20:50:43Z Feeding 216 bytes of dynamic environment data into RNG
```
This PR:
```bash
2019-12-23T20:32:41Z Feeding 232 bytes of dynamic environment data into RNG
2019-12-23T20:33:42Z Feeding 232 bytes of dynamic environment data into RNG
```
~~Depends on #16392.~~ Merged.
ACKs for top commit:
laanwj:
ACK dc9305b6162ec615ff5fb2876e4f312051b543af
Tree-SHA512: 18c2f336ea628f9cf7339b817381d230a18893fd9c0351bf99a39ca6f45c5b0a20af9d599d48d6c09515627d5edafa91337c17f9f790264251d2cdcb3763bbd5
55b2cb199c276781b6daa5438af2da57dea3ac52 random: mark RandAddPeriodic and SeedPeriodic as noexcept (fanquake)
461e547877da0c04db69e067c923cc4540aab03a doc: correct random.h docs after #17270 (fanquake)
Pull request description:
The usage of `MilliSleep()` in SeedPeriodic (previously SeedSleep) was
[removed](d61f2bb076) in #17270, meaning it, and its users can now be marked `noexcept`.
This also corrects the docs in random.h for some of the changes in #17270.
ACKs for top commit:
practicalswift:
ACK 55b2cb199c276781b6daa5438af2da57dea3ac52
laanwj:
ACK 55b2cb199c276781b6daa5438af2da57dea3ac52
sipa:
ACK 55b2cb199c276781b6daa5438af2da57dea3ac52
Tree-SHA512: 672d369796e7c4f9b4d98dc545e5454999fa1bef373871994a26041d6163c58909e2255e4f820d3ef011679aa3392754eb57477306a89f5fd3d57e2bd7f0811a
f93fc61c65d605eae2d3e2c98bdd30ae587fcdab Put bounds on the number of CPUID leaves explored (Pieter Wuille)
ba2c5fe1477cec80d7e02f824daba21a1021758e Fix CPUID subleaf iteration (Pieter Wuille)
Pull request description:
This fixes#17523.
The code to determine which CPUID subleaves to explore was incorrect in #17270. The new code here is based on Intel's reference documentation for CPUID (a document called "Intel® Processor Identification and the CPUID Instruction - Application Note 485", which I cannot actually find on their own website).
ACKs for top commit:
laanwj:
ACK f93fc61c65d605eae2d3e2c98bdd30ae587fcdab
jonatack:
ACK f93fc61c65d605eae2d3e2c98bdd30ae587fcdab code review, tested rebased on current master bb862d7 with Debian 4.19 x86_64
mzumsande:
ACK f93fc61, reviewed code and compared with the intel doc, tested on an AMD and an Intel processor.
Tree-SHA512: 2790b326fa397b736c0f39f25807bea57de2752fdd58bf6693d044b8cb26df36c11cce165a334b471f8e33724f10e3b76edab5cc4e0e7776601aabda13277245