33f5fc32e5bfbe1e89c4d20ce455bcc6dc194151 test: add rpc getaddressinfo labels test coverage (Jon Atack)
0f3539ac6d772fc646b5f184fa1efe77bf632f6a test: add listlabels test in wallet_labels.py (Jon Atack)
1388de83900eaced906d369fe9e8887ae74b2dcf rpc: add getaddressinfo code documentation (Jon Atack)
2ee0cb3330ccf70f0540cb42370796e32eff1569 rpc: update getaddressinfo RPCExamples to bech32 (Jon Atack)
8d1ed0c263f8cdff7189f02040b5d02238d93da0 rpc: clarify label vs labels in getaddressinfo RPCHelpman (Jon Atack)
5a0ed850700dfb19167d40b38f80313bd5e427ca rpc: improve getaddressinfo RPCHelpman content (Jon Atack)
70cda342cd20d0e0cd9f28405457544036968f2d rpc: improve getaddressinfo RPCHelpman formatting (Jon Atack)
Pull request description:
This PR is a continuation of the work in https://github.com/bitcoin/bitcoin/pull/12892.
Main motivations:
- There is currently no test coverage for the getaddressinfo `labels` response. Coverage here is a prerequisite before deprecating the `label` response or adding multiple labels per address.
- `bitcoin-cli help getaddressinfo` returns a few content errors, difficult-to-read formatting, and no explanation why it returns both `label` and `labels` and how they relate, which can be confusing for application developers.
Changes by order of commits:
- [x] improve/fix getaddressinfo RPCHelpman layout formatting
- [x] improve/fix getaddressinfo RPCHelpman content
- [x] clarify the `label` and `labels` fields in getaddressinfo RPCHelpman
- [x] update getaddressinfo RPCExamples addresses to bech32
- [x] add getaddressinfo code docs
- [x] add a `listlabels` test assertion in wallet_labels.py
- [x] add missing getaddressinfo `labels` test coverage and improve the existing `label` tests
Here are gists of the CLI help output:
[`bitcoin-cli help getaddressinfo` before this PR](https://gist.github.com/jonatack/022af5221a85c069780359a22643c810)
[`bitcoin-cli help getaddressinfo` after this PR](https://gist.github.com/jonatack/4ee5f6abc62a3d99269570206a5f90ba)
It seems we ought to begin a deprecation process for the getaddressinfo `label` field? If yes, I have a follow-up ready. _--> EDIT: Deprecation follow-ups #17578 and #17585 now build on this PR._
ACKs for top commit:
fjahr:
Re-ACK 33f5fc32e5bfbe1e89c4d20ce455bcc6dc194151
jnewbery:
ACK 33f5fc32e5bfbe1e89c4d20ce455bcc6dc194151.
Tree-SHA512: a001aa863090ec2566a31059477945b1c303ebeb430b33472f8b150e420fa5742fc33bca9d95571746395b607f43f6078dd5b53e238ac1f3fc648b51c8f79a07
27d82b63fb8869716d2f103fd381c2413bde4d1b gui: remove macOS start on login code (fanquake)
Pull request description:
The macOS startup item code was disabled for builds targeting macOS >
`10.11` in #15208. Now that we require macOS `10.12` as a minimum (#17550),
we can remove the startup item code entirely. The API we were using, `LSSharedFileListItemCopyResolvedURL`, `LSSharedFileListCopySnapshot` etc,
was removed in macOS `10.12` SDK.
ACKs for top commit:
jonasschnelli:
utACK 27d82b63fb8869716d2f103fd381c2413bde4d1b
jonasschnelli:
Tested ACK 27d82b63fb8869716d2f103fd381c2413bde4d1b - successfully compiled on 10.15.1
Tree-SHA512: 7420757b91c7820e6a63280887155394547134a9cebcf3721af0284da23292627f94cd431241e033075b3fd86d79ace3ebf1b25d17763acbf71e07a742395409
93352d261fa4e1518a4f006de157ff5a2fc4c819 qt: Use proper class for Ui::ReceiveCoinsDialog (Hennadii Stepanov)
87819046432a24fa8a7ec5c115eae4df0d281245 qt: Fix class name of Ui::ModalOverlay (Hennadii Stepanov)
Pull request description:
Use proper classes for:
- `Ui::ModalOverlay` to remove `<customwidget>` entry
- `Ui::ReceiveCoinsDialog` to be consistent with the code base
This PR does not change behavior.
ACKs for top commit:
jonasschnelli:
Tested ACK 93352d261fa4e1518a4f006de157ff5a2fc4c819 - ran this on top of master and tested the modal overlay on initial mainnet sync.
laanwj:
code review ACK 93352d261fa4e1518a4f006de157ff5a2fc4c819
Tree-SHA512: faeed8e86dbf5355505defcdb7e1db07d6a6005ee5eb07367b00f6aa122dd8ad34f8372d4bae7b29c0eac87b538a33157e19328be2876135e8a6376a3197f1bc
1a3a256d5e0443d19757c1f1fceb9c9ede17758a wallet: replace raw pointer with const reference in AddrToPubKey (Harris)
Pull request description:
This PR replaces a redundant reference-to-pointer conversion in **addmultisigaddress** from *wallet/rpcwallet.cpp*. It also makes the API from *rpc/util.h* look more straightforward as **AddrToPubKey** now uses const references like other functions from there.
I am not sure why there is a ref-to-ptr conversion in addmultisignatures, so I can only speculate that this is because of "historical reasons".
The ref-to-ptr conversion happens here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L1001
There, the address of LegacyScriptPubKeyMan& is given to AddrToPubKey.
Later, in AddrToPubKey, it gets converted back to a reference, because GetKeyForDestination in rpc/util.cpp expects a const ref: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/util.cpp#L140
Regards,
ACKs for top commit:
achow101:
ACK 1a3a256d5e0443d19757c1f1fceb9c9ede17758a
meshcollider:
utACK 1a3a256d5e0443d19757c1f1fceb9c9ede17758a
promag:
Code review ACK 1a3a256d5e0443d19757c1f1fceb9c9ede17758a.
hebasto:
ACK 1a3a256d5e0443d19757c1f1fceb9c9ede17758a, I have not tested the code, but I have reviewed it and it looks OK, I agree it can be merged.
Tree-SHA512: 1a2b8ddab5694ef4c65fac69f011e38dd03a634e84a35857e13bd05ad99fe42af22ee0af6230865e3d2c725693512f3336acb055ede19c958424283e7a3856c4
da1f153e5e260f1744ee1bf4f24ca3a74ffea465 Add s390x tests to travis (Elichai Turkel)
2fa65e0de94f01d502e8ace89be3c5dc963dd764 Add ci script to install on s390x (Elichai Turkel)
Pull request description:
Discovered this as part of #17402 and a conversation with gmaxwell.
You can see here that the platform is indeed BE: https://travis-ci.org/elichai/bitcoin/jobs/616656410#L36
This closes https://github.com/bitcoin/bitcoin/issues/6466
ACKs for top commit:
MarcoFalke:
ACK da1f153e5e260f1744ee1bf4f24ca3a74ffea465
Tree-SHA512: e7e94e54e220257d91b24fddc79eab2bcaaadf0b2d1e7e6872d9757808ab2541728f00b1f3ab7e343305c0e7d91bb48a17a3f9621f6fff6c9fe6cde6682de408
41d7db0b60375533934af3e3b48043e6de944bd1 doc: Change doxygen URL to doxygen.bitcoincore.org (Wladimir J. van der Laan)
Pull request description:
The bitcoin core doxygen documentation has moved to https://doxygen.bitcoincore.org, see bitcoin-core/bitcoincore.org#681
(the old URL still works as a redirect)
ACKs for top commit:
Sjors:
ACK 41d7db0b60375533934af3e3b48043e6de944bd1 based on a short spot check.
fanquake:
ACK 41d7db0b60375533934af3e3b48043e6de944bd1 - also checked the redirect.
Tree-SHA512: e6fa0477b7825e3557c1b3bed8c5a37c33188ddcba43e6a19f95d86618408f7d04bbaeb64bd79181930c5af1252ca5c462e3f7a850bfffa39a8f62bcccbb4260
f13e274b6f8ada41ebcd3e746b38c7577074f6f9 Appveyor install libevent[thread] vcpkg (Aaron Clauson)
Pull request description:
As per #17586 the default libevent vcpkg install now has thread disabled. This PR installs libevent with the thread feature enabled.
Top commit has no ACKs.
Tree-SHA512: 5448113f0444170777400fef3582719845ca50d61d9382dfaacc55c43d477dd714456e38a3094e9b6858d93e84def11c2efa46902b52648c9f0c9362cc909147
eafd2593674b6890418a50eadf69425071b824e4 build: Add NX workaround for RV64 (Wladimir J. van der Laan)
f6e42256fe8900ed90f9644906b77f97e1600952 build: Allow export of environ symbols (Wladimir J. van der Laan)
Pull request description:
This export was introduced in #17270 which added
```
//! Necessary on some platforms
extern char** environ;
```
This should (finally) make the gitian build pass again (fix issue #17525.).
Built on top of #17538 which should be merged first.
Top commit has no ACKs.
Tree-SHA512: 5c2054d52d0957aec3dc945b76d8e219187d22dc03889e7a88fb76049bf8e4a3e9f4da00dd1e9dd0351211f8e70d1a1b8ad7244f0348dab698e9d14b9d0c0bd4
8f15a317602727d24f60d0bbf43f851b33df3228 doc: add glibc 2.17 requirement to release-notes (fanquake)
16a7be1663b02ddefa1e4f0309be49b725ffb388 build: Bump minimum versions in symbol checker (Wladimir J. van der Laan)
b77d5ad59fb9f3f26d919ee6c33ae732382de504 build: Disallow dynamic linking against c++ library (Wladimir J. van der Laan)
Pull request description:
Closes: #17525. Taken over from #17531.
Debian 8 (Jessie) has:
- g++ version 4.9.2
- libc version 2.19
CentOS 7 has:
- g++ version 4.8.5
- libc version 2.17
Ubuntu 16.04.4 (Xenial, oldest supported Ubuntu) has:
- g++ version 5.3.1
- libc version 2.23.0
Taking the minimum of these as our target. According to [GNU ABI document](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html) this corresponds to:
- GCC 4.8.5: GCC_4.8.0
- (glibc) GLIBC_2_17
This also contains a (long needed) commit to disallow dynamic linking to stdc++, as our releases statically link against that.
ACKs for top commit:
laanwj:
re-ACK 8f15a317602727d24f60d0bbf43f851b33df3228
Tree-SHA512: a3cc92aa1c5de253b1531f4b854d6f5f4a15d614ba6290d9db293542a96994b55c4a8e33e03b601bae16eb65529630b4f94b48b010e0b66b7dc9ff0acf945107
14feda0814a9fecf2138041f7d36fe1ab338797f doc: Add historical release notes for 0.19.0.1 (Wladimir J. van der Laan)
Pull request description:
Add historical release notes for 0.19.0.1. And replace 0.19.0's release notes with a short explanation.
Top commit has no ACKs.
Tree-SHA512: 3551250c8b0643a96b645af9088ef07a079452bad3abf2b5653563f5ecbc07fc1e1c6adcd56eb9fa6e3e7637719b3b99253b95bce409a9267a428323b559bfa3
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
794fe91395c79f46a6d920bc08de5a0551b359a3 doc: Update and improve Developer Notes (Hennadii Stepanov)
Pull request description:
This PR:
- removes outdated things, e.g., global pointer `pwalletMain` etc
- adds "Sanitizers" to the TOC
- makes filenames, `peer.dat` and `debug.log`, monospaced
- specifies that _compile-time_ constant names are all uppercase
- rewords using `explicit` with constructors
ACKs for top commit:
jamesob:
lazy ACK 794fe91395
practicalswift:
ACK 794fe91395c79f46a6d920bc08de5a0551b359a3 -- nice improvements!
Tree-SHA512: 2c5f035b1627f5fac8dc2453199d9e46bd101f86771de567cd95698de3c61cc459444ec1a68710e1d280195e1e40b42d9f40906297d12f12bf37749eca58297d
An opportunistic TopUp is moved from LegacyScriptPubKeyMan::GetNewDestination
to CWallet::GetNewDestination. Another opportunistic TopUp is moved from
LegacyScriptPubKeyMan::ReserveKeyFromKeyPool (called by LegacyScriptPubKeyMan::GetReservedDestination)
to ReserveDestination::GetReservedDestination.
Moving opportunistic TopUps ensures that ScriptPubKeyMans will always
be topped up before requesting Destinations from them as we cannot
always rely on future ScriptPubKeyMan implementaions topping up internally.
As such, it is also unnecessary to keep the TopUp calls in the
LegacyScriptPubKeyMan functions so they are moved.
This does not change behavior as TopUp calls are moved up the call stack.
