| Age | Commit message (Collapse) | Author |
|---|
|
faf1af58f85da74f94c6b5f6910c7faf7b47cc88 fuzz: Add Temporary debug assert for oss-fuzz issue (MarcoFalke)
Pull request description:
oss-fuzz is acting weird, so add an earlier assert to help troubleshooting
ACKs for top commit:
practicalswift:
cr ACK faf1af58f85da74f94c6b5f6910c7faf7b47cc88
Tree-SHA512: 85830d7d47cf6b4edfe91a07bd5aa8f7110db0bade8df93868cf276ed04d5dd17e671f769e6a0fb5092012b86aa82bb411fb171411f15746981104ce634c88c1
|
|
fa483e9f68b8b4171dabb25cc88dc2eada454a99 fuzz: Speed up crypto fuzz target (MarcoFalke)
Pull request description:
May fix https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34962
Similar solution to https://github.com/bitcoin/bitcoin/pull/22005
ACKs for top commit:
practicalswift:
cr ACK fa483e9f68b8b4171dabb25cc88dc2eada454a99: patch looks correct and rationale makes sense
Tree-SHA512: 3788cf9f6ba0f7a0a217cd3a6a825839689425e99e4d6d657981d291a001b0da7c5abb50a68b4ee1c2a8300b87fb92e4e3ccc1171907792b40251e467c33bd53
|
|
|
|
|
|
rejected due to too-new tim…
754e802274e9373ad7e1dccb710acf74ded6e7fb test: check rejected future block later accepted (Luke Dashjr)
Pull request description:
(Luke) was unsure if the code sufficiently avoided caching a
time-too-new rejection, so wrote this test to check it. It looks like
despite only exempting BLOCK_MUTATED, it is still okay because header
failures never cache block invalidity. This test will help ensure that
if this ever changes, BLOCK_TIME_FUTURE gets excluded at the same time.
This PR re-opens https://github.com/bitcoin/bitcoin/pull/17872 which went stale and addresses the nits raised by reviewers there.
ACKs for top commit:
MarcoFalke:
review ACK 754e802274e9373ad7e1dccb710acf74ded6e7fb
Tree-SHA512: a2bbc8fffb523cf2831e1ecb05f20868e30106a38cc2e369e4973fa549cca06675a668df16f76c49cc4ce3a22925404255e5c53c4232d63ba1b9fca878509aa0
|
|
and hierarchy
e2c40a4ed5272d72fea997bd936fba28bb753226 guix-attest: Error out if SHA256SUMS is unexpected (Carl Dong)
4cc35daed557f38b080360a89036b2e97a6f78c2 Rewrite guix-{attest,verify} for new hier (Carl Dong)
28a9c9b83924f585b397f0f3b8e9e73780ac0ad6 Make SHA256SUMS fragment right after build (Carl Dong)
Pull request description:
Based on: #22075
Code reviewers: I recommend reading the new `guix-{attest,verify}` files instead of trying to read the diff
The following changes resolve many usability improvements which were pointed out to me:
1. Some maintainers like to extract their "uncodesigned tarball" inside the `output/` directory, resulting in the older `guix-attest` mistakenly attesting to the extracted contents
2. Maintainers whose GPG keys reside on an external smartcard often need to physically interact with the smartcard as a way to approve the signing operation, having one signature per platform means a lot of fidgeting
3. Maintainers wishing to sign on a separate machine now has the option of transferring only a subtree of `output/`, namely `output/*/SHA256SUMS.part`, in order to perform a signature (you may need to specify an `$OUTDIR_BASE` env var)
4. An `all.SHA256SUMS` file should be usable as the base `SHA256SUMS` in bitcoin core torrents and on the release server.
For those who sign on an separate machine than the one you do builds on, the following steps will work:
1. `env GUIX_SIGS_REPO=/home/achow101/guix.sigs SIGNER=achow101 NO_SIGN=1 ./contrib/guix/guix-attest`
2. Copy `/home/achow101/guix.sigs/<tag>/achow101` (which does not yet have signatures) to signing machine
3. Sign the `SHA256SUMS` files:
```bash
for i in "<path-to-achow101>/*.SHA256SUMS"; do
gpg --detach-sign --local-user "<your-key-here>" --armor --output "$i"{.asc,}
done
```
5. Upload `<path-to-achow101>` (now with signatures) to `guix.sigs`
-----
After this change, output directories will now include a `SHA256SUMS.part` fragment, created immediately after a successful build:
```
output
└── x86_64-w64-mingw32
├── bitcoin-4e069f7589da-win64-debug.zip
├── bitcoin-4e069f7589da-win64-setup-unsigned.exe
├── bitcoin-4e069f7589da-win64.zip
├── bitcoin-4e069f7589da-win-unsigned.tar.gz
└── SHA256SUMS.part
```
These `SHA256SUMS.part` fragments look something like:
```
3ebd7262b1a0a5bb757fef1f70e7e14033c70f98c059bc4dbfee5d1992b25825 dist-archive/bitcoin-4e069f7589da.tar.gz
def2e7d3de5ab3e3f955344e75151df4f33713f9101f5295bd13c9375bdf633b x86_64-w64-mingw32/bitcoin-4e069f7589da-win64-debug.zip
643049fe3ee4a4e83a1739607e67b11b7c9b1a66208a6f35a9ff634ba795500e x86_64-w64-mingw32/bitcoin-4e069f7589da-win64-setup-unsigned.exe
a247a1ccec0ccc2e138c648284bd01f6a761f2d8d6d07d91b5b4a6670ec3f288 x86_64-w64-mingw32/bitcoin-4e069f7589da-win-unsigned.tar.gz
fab76a836dcc592e39c04fd2396696633fb6eb56e39ecbf6c909bd173ed4280c x86_64-w64-mingw32/bitcoin-4e069f7589da-win64.zip
```
Meaning that they are valid `SHA256SUMS` files when `sha256sum --check`'d at the `guix-build-*/output` directory level
When `guix-attest` is invoked, these `SHA256SUMS.part` files are combined and sorted (by `-k2`, `LC_ALL=C`) to create:
1. `noncodesigned.SHA256SUMS` for a manifest of all non-codesigned outputs, and
3. `all.SHA256SUMS` for a manifest of all outputs including non-codesigned outputs
Then both files are signed, resulting in the following `guix.sigs` hierarchy:
```
4e069f7589da/
└── dongcarl
├── all.SHA256SUMS
├── all.SHA256SUMS.asc
├── noncodesigned.SHA256SUMS
└── noncodesigned.SHA256SUMS.asc
```
ACKs for top commit:
achow101:
ACK e2c40a4ed5272d72fea997bd936fba28bb753226
hebasto:
ACK e2c40a4ed5272d72fea997bd936fba28bb753226, tested on Linux Mint 20.1 (x86_64) with and w/o `NO_SIGN=1`. Changes in `contrib/guix/libexec/codesign.sh` and `contrib/guix/guix-verify` are reviewed only.
Tree-SHA512: 618aacefb0eb6595735a9ab6a98ea6598fce65f9ccf33fa1e7ef93bf140c0f6cfc16e34870c6aa3e4777dd3f004b92a82a994141879870141742df948ec59c1f
|
|
reduce #ifdef
2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd gui: misc external signer fixes and translation hints (Sjors Provoost)
d672404466204444a1d9f2d3498de4448f53d2be refactor: make ExternalSigner NetworkArg() and m_chain private (Sjors Provoost)
4455145e266450397b45acd7286686966edd072b refactor: reduce #ifdef ENABLE_EXTERNAL_SIGNER usage (Sjors Provoost)
5be90c907eba0a38019c7d9826623d5d5f567c66 build: enable external signer by default (Sjors Provoost)
7d9453041b827bafbdfc1ac0b01c7b7e1ee2bd4f refactor: clean up external_signer.h includes (Sjors Provoost)
fc0eca31b33f87882e2aa329a3746d4e08af1985 fuzz: fix fuzz binary linking order (Sjors Provoost)
Pull request description:
This follows the introduction of GUI support in https://github.com/bitcoin-core/gui/pull/4
I don't think we should expect GUI users to self compile. This also enables external signer support by default for RPC users.
In addition this PR reduces the number of `#ifdef ENABLE_EXTERNAL_SIGNER`, which also fixes #21919. When compiled with `--disable-external-signer` such wallets can't be created in RPC or GUI, but they can be loaded. Attempting any action that calls HWI will trigger an error.
Side-note: this PR may or may not (currently) break CI for the GUI repository, as explained here: https://github.com/bitcoin-core/gui/pull/4#issuecomment-769859001
ACKs for top commit:
achow101:
ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd
hebasto:
re-ACK 2f5bdcbc31a2eeb7c11226a9e51c56f02ac807dd
Tree-SHA512: 1b71c5a8bea2be077ee9fa33a01130c957a0cf90951d4b7b04d3d0ef826bb77e474c3963abddfef2e2c1ea99d9c72cd2302d1eb9b5fcb7ba0bd2a625f006aa05
|
|
when external warnings are enabled
1111457d7433c2cca1d7e98946f6954e3a0280ef build: Disable deprecated-copy warning only when external warnings are enabled (MarcoFalke)
Pull request description:
Fixes https://github.com/bitcoin/bitcoin/issues/18967
Alternative to https://github.com/bitcoin/bitcoin/pull/22240
ACKs for top commit:
fanquake:
tACK 1111457d7433c2cca1d7e98946f6954e3a0280ef
Tree-SHA512: 0fc826f26ebbeab662fa7eed2a5cc1630c6c4e612deb91734885fc8bae0352be657ec48ae94ff55a984ac36d27b95cea8d947cc5cf408231d56addecf79db83f
|
|
|
|
|
|
|
|
In particular this make the node interface independent on whether external signer support is compiled.
|
|
|
|
Co-Authored-By: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
|
|
We encountered a linking error when attempting to include external_signer_scriptpubkeyman.cpp when configured with --disable-external-signer.
Everywhere else we have LIBBITCOIN_WALLET, it is always before LIBBITCOIN_COMMON. But if you go up to where FUZZ_SUITE_LD_COMMON is first set, you see that we will end up having LIBBITCOIN_COMMON set before LIBBITCOIN_WALLET which means that the linker will have problems linking things common things that the wallet uses. Because the order is correct for the other targets, we only see a linker error for test/fuzz/fuzz.
In this diff, LIBTEST_UTIL and LIBTEST_FUZZ are moved to the top because they include LIBBITCOIN_SERVER and LIBBITCOIN_COMMON. LIBBITCOIN_SERVER always needs to be the first item in the linker order since it has the most dependencies.
The makefiles for making the fuzz and test binaries should be revisited so that the linking order is made consistent with the rest of the code and to avoid other linker order issues that may crop up in the future.
Co-Authored-By: Andrew Chow <achow101-github@achow101.com>
|
|
79c02c88b347f1408a2db307db2654917f9b0bcc Randomize message processing peer order (Pieter Wuille)
Pull request description:
Right now, the message handling loop iterates the list of nodes always in the same order: the order they were connected in (see the `vNodes` vector). For some parts of the net processing logic, this order matters. Transaction requests are assigned explicitly to peers since #19988, but many other parts of processing work on a "first-served-by-loop-first" basis, such as block downloading. If peers can predict this ordering, it may be exploited to cause delays.
As there isn't anything particularly optimal about the current ordering, just make it unpredictable by randomizing.
Reported by Crypt-iQ.
ACKs for top commit:
jnewbery:
ACK 79c02c88b3
Crypt-iQ:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
sdaftuar:
utACK 79c02c88b347f1408a2db307db2654917f9b0bcc
achow101:
Code Review ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
jamesob:
crACK https://github.com/bitcoin/bitcoin/pull/22144/commits/79c02c88b347f1408a2db307db2654917f9b0bcc
jonatack:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
vasild:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
theStack:
ACK 79c02c88b347f1408a2db307db2654917f9b0bcc
Tree-SHA512: 9a87c4dcad47c2d61b76c4f37f59674876b78f33f45943089bf159902a23e12de7a5feae1a73b17cbc3f2e37c980ecf0f7fd86af9e6fa3a68099537a3c82c106
|
|
(Luke) was unsure if the code sufficiently avoided caching a
time-too-new rejection, so wrote this test to check it. It looks like
despite only exempting BLOCK_MUTATED, it is still okay because header
failures never cache block invalidity. This test will help ensure that
if this ever changes, BLOCK_TIME_FUTURE gets excluded at the same time.
Co-authored-by: Will Clark <will8clark@gmail.com>
|
|
aab7fd0f8ddb34437a63d636170f5051aae285b4 Switch Appveyor CI to VS2019 stable image (Aaron Clauson)
Pull request description:
The current appveyor config is using the VS2019 preview image so the latest prebuilt Qt5.12.11 binaries can be used, see #22224.
Appveyor updated the Visual Studio 2019 image to msbuild v16.10.1 on 14th of June. This is the version used to build the latest Qt binaries and removes the need to use the Appveyor VS2019 preview image.
ACKs for top commit:
MarcoFalke:
review ACK aab7fd0f8ddb34437a63d636170f5051aae285b4 if green
practicalswift:
cr ACK aab7fd0f8ddb34437a63d636170f5051aae285b4: patch looks correct
hebasto:
ACK aab7fd0f8ddb34437a63d636170f5051aae285b4
Tree-SHA512: 42ea4e6e27a2099ddeed99a3352e8ff014df1e93fbcb1f0f2ebd6f22ec2fb71212275a2adb2a7858516203e566c6ba053367b4ac7e0b74457f7a35e941d6fdd4
|
|
e4c916a0ea0637f4a765b1cb57ee10abef6fb4d6 Bugfix: GUI: Use a different shortcut for "1 d&ay" banning, due to conflict with "&Disconnect" (Luke Dashjr)
94e7cdd7e04ca79f89474df1400e1a189e068939 GUI: Add keyboard shortcuts for other context menus (Luke Dashjr)
02b5263cd4e02aa540cab35c2bf6cf9eda3522ae GUI: Restore keyboard shortcuts for context menu entries (Luke Dashjr)
Pull request description:
Various keyboard shortcuts were lost in #263; this restores them, and also adds new ones for other context menus.
Note that with a context menu open, simply the shortcut by itself (no Alt) is used.
ACKs for top commit:
jarolrod:
Code Review ACK e4c916a
hebasto:
ACK e4c916a0ea0637f4a765b1cb57ee10abef6fb4d6, tested on Linux Mint 20.1 (Qt 5.12.8).
Tree-SHA512: 949461acf7aac592bc48a1c5abad41b167365830e0cedb3aa11b6a87bd347e16126830ea87936f9c9efc4b7df5b09d3833fae784964d6d119ed45703cfba2ffd
|
|
|
|
The current appveyor config is using the VS2019 preview image so the latest prebuilt Qt5.12.11 binaries can be used, see #22224.
Appveyor updated the Visual Studio 2019 image to msbuild v16.10.1 on 14th of June. This is the version used to build the latest Qt binaries and removes the need to use the Appveyor VS2019 preview image.
|
|
ae98aec9c0521cdcec76459c8200bd45ff6a1485 refactor: Make CAddrMan::cs non-recursive (Hennadii Stepanov)
f5d1c7fac70f424114dae3be270fdc31589a8c34 Add AssertLockHeld to CAddrMan private functions (Hennadii Stepanov)
5ef1d0b6982f05f70ff2164ab9af1ac1d2f97f5d Add thread safety annotations to CAddrMan public functions (Hennadii Stepanov)
b138973a8b4bbe061ad97011f278a21e08ea79e6 refactor: Avoid recursive locking in CAddrMan::Clear (Hennadii Stepanov)
f79a664314b88941c1a2796623e846d0a5916c06 refactor: Apply consistent pattern for CAddrMan::Check usage (Hennadii Stepanov)
187b7d2bb36e6de9cd960378021ebe690619a2ef refactor: Avoid recursive locking in CAddrMan::Check (Hennadii Stepanov)
f77d9c79aa41dab4285e95c9432cc6d853be67a3 refactor: Fix CAddrMan::Check style (Hennadii Stepanov)
06703973c758c2c5d0ff916993aa7055f609d2d7 Make CAddrMan::Check private (Hennadii Stepanov)
efc6fac951e75ba913350bb470c3d4e6a4e284b9 refactor: Avoid recursive locking in CAddrMan::size (Hennadii Stepanov)
2da95545ea42f925dbc7703e42e9356908a8c83e test: Drop excessive locking in CAddrManTest::SimConnFail (Hennadii Stepanov)
Pull request description:
This PR replaces `RecursiveMutex CAddrMan::cs` with `Mutex CAddrMan::cs`.
All of the related code branches are covered by appropriate lock assertions to insure that the mutex locking policy has not been changed by accident.
Related to #19303.
Based on #22025, and first three commits belong to it.
ACKs for top commit:
vasild:
ACK ae98aec9c0521cdcec76459c8200bd45ff6a1485
Tree-SHA512: c3a2d3d955a75befd7e497a802b8c10730e393be9111ca263ad0464d32fae6c7edf9bd173ffb6bc9bb61c4b39073a74eba12979d47f26b0b7b4a861d100942df
|
|
|
|
|
|
|
|
Co-authored-by: John Newbery <john@johnnewbery.com>
|
|
Co-authored-by: John Newbery <john@johnnewbery.com>
|
|
|
|
This change improves readability, and follows Developer Notes.
|
|
Change in the addrman.h header is move-only.
|
|
|
|
The unit test is single threaded, so there's no need to hold the mutex
between Good() and Attempt().
This change avoids recursive locking in the CAddrMan::Attempt function.
Co-authored-by: John Newbery <john@johnnewbery.com>
|
|
multiple networks, add I2P peers
1b1088d52fbff8b1c9438d6aa8c6edcbdd471457 test: add combined I2P/onion/localhost eviction protection tests (Jon Atack)
7c2284eda22a08dbf2a560894e496e245d026ee0 test: add tests for inbound eviction protection of I2P peers (Jon Atack)
ce02dd1ef1f7f54f33780b32f195d31c1cc87318 p2p: extend inbound eviction protection by network to I2P peers (Jon Atack)
70bbc62711643ec57cce620f9f7a0e1fe5fb6346 test: add combined onion/localhost eviction protection coverage (Jon Atack)
045cb40192bf3dfa6c42916237e55f86bbc788d4 p2p: remove unused m_is_onion member from NodeEvictionCandidate struct (Jon Atack)
310fab49282d507e5fa710afb20d036604bbf3a2 p2p: remove unused CompareLocalHostTimeConnected() (Jon Atack)
9e889e8a5c021b0ec7e4c4d17d418ab4a0accad4 p2p: remove unused CompareOnionTimeConnected() (Jon Atack)
787d46bb2a39fb39166882cc6e0afbc34424d88e p2p: update ProtectEvictionCandidatesByRatio() doxygen docs (Jon Atack)
1e15acf478ae071234350c9b38dc823dfe2e3419 p2p: make ProtectEvictionCandidatesByRatio() fully ratio-based (Jon Atack)
3f8105c4d251e0e81bdd31f0999004e36f8990b2 test: remove combined onion/localhost eviction protection tests (Jon Atack)
38a81a8e20b0e5ad9fef0eae8abd914619f05b25 p2p: add CompareNodeNetworkTime() comparator struct (Jon Atack)
4ee7aec47ebf6b59b4d930e6e4025e91352c05b4 p2p: add m_network to NodeEvictionCandidate struct (Jon Atack)
7321e6f2fe1641eb331f30e68646f5984d4bcbb3 p2p, refactor: rename vEvictionCandidates to eviction_candidates (Jon Atack)
ec590f1d91325404383d74098a5b42a2cd67dad9 p2p, refactor: improve constness in ProtectEvictionCandidatesByRatio() (Jon Atack)
4a19f501abac4adb476a6f2a30dfdf1a35892ccc test: add ALL_NETWORKS to test utilities (Jon Atack)
519e76bb64d03ecac175ec33c31e37d0e90f037f test: speed up and simplify peer_eviction_test (Jon Atack)
1cde8005233d163723d4d5bf1bacf22e6cb7a07e p2p, refactor: rm redundant erase_size calculation in SelectNodeToEvict() (Jon Atack)
Pull request description:
Continuing the work in #20197 and #20685, this pull updates and abstracts our inbound eviction protection to make it fully ratio-based and easily extensible to peers connected via high-latency privacy networks that we newly support, like I2P and perhaps others soon, as these peers are disadvantaged by the latency criteria of our eviction logic.
It then adds eviction protection for peers connected over I2P. As described in https://github.com/bitcoin/bitcoin/pull/20685#issuecomment-767486499, we've observed over the past few months that I2P peers have a min ping latency similar to or greater than that of onion peers.
The algorithm is a basically a multi-pass knapsack:
- Count the number of eviction candidates in each of the disadvantaged
privacy networks.
- Sort the networks from lower to higher candidate counts, so that
a network with fewer candidates will have the first opportunity
for any unused slots remaining from the previous iteration. In
the case of a tie in candidate counts, priority is given by array
member order from first to last, guesstimated to favor more unusual
networks.
- Iterate through the networks in this order. On each iteration,
allocate each network an equal number of protected slots targeting
a total number of candidates to protect, provided any slots remain
in the knapsack.
- Protect the candidates in that network having the longest uptime,
if any in that network are present.
- Continue iterating as long as we have non-allocated slots
remaining and candidates available to protect.
The goal of this logic is to favorise the diversity of our peer connections.
The individual commit messages describe each change in more detail.
Special thank you to Vasil Dimov for the excellent review feedback and the algorithm improvement that made this change much better than it would have been otherwise. Thanks also to Antoine Riard, whose review feedback nudged this change to protect disadvantaged networks having fewer, rather than more, eviction candidates.
ACKs for top commit:
laanwj:
Code review re-ACK 1b1088d52fbff8b1c9438d6aa8c6edcbdd471457
vasild:
ACK 1b1088d52fbff8b1c9438d6aa8c6edcbdd471457
Tree-SHA512: 722f790ff11f2969c79e45a5e0e938d94df78df8687e77002f32e3ef5c72a9ac10ebf8c7a9eb7f71882c97ab0e67b2778191effdb747d9ca54d7c23c2ed19a90
|
|
|
|
|
|
This commit extends our inbound eviction protection to I2P peers to
favorise the diversity of peer connections, as peers connected
through the I2P network are otherwise disadvantaged by our eviction
criteria for their higher latency (higher min ping times) relative
to IPv4 and IPv6 peers, as well as relative to Tor onion peers.
The `networks` array is order-dependent in the case of a tie in
candidate counts between networks (earlier array members receive
priority in the case of a tie).
Therefore, we place I2P candidates before localhost and onion ones
in terms of opportunity to recover unused remaining protected slots
from the previous iteration, guesstimating that most nodes allowing
both onion and I2P inbounds will have more onion peers, followed by
localhost, then I2P, as I2P support is only being added in the
upcoming v22.0 release.
|
|
|
|
|
|
|
|
|
|
|
|
with a more abstract framework to allow easily extending inbound
eviction protection to peers connected through new higher-latency
networks that are disadvantaged by our inbound eviction criteria,
such as I2P and perhaps other BIP155 networks in the future like
CJDNS. This is a change in behavior.
The algorithm is a basically a multi-pass knapsack:
- Count the number of eviction candidates in each of the disadvantaged
privacy networks.
- Sort the networks from lower to higher candidate counts, so that
a network with fewer candidates will have the first opportunity
for any unused slots remaining from the previous iteration. In
the case of a tie in candidate counts, priority is given by array
member order from first to last, guesstimated to favor more unusual
networks.
- Iterate through the networks in this order. On each iteration,
allocate each network an equal number of protected slots targeting
a total number of candidates to protect, provided any slots remain
in the knapsack.
- Protect the candidates in that network having the longest uptime,
if any in that network are present.
- Continue iterating as long as we have non-allocated slots
remaining and candidates available to protect.
Localhost peers are treated as a network like Tor or I2P by aliasing
them to an unused Network enumerator: Network::NET_MAX.
The goal is to favorise diversity of our inbound connections.
Credit to Vasil Dimov for improving the algorithm from single-pass
to multi-pass to better allocate unused protection slots.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
|
|
with "&Disconnect"
|
|
bitcoin-qt.exe
9edd713c184bd6b92ff7862d0df8f1a89062e9d3 build: Fix MSVC linker /SubSystem option for bitcoin-qt.exe (Hennadii Stepanov)
Pull request description:
On master (6f3fbc062f97183f19a8551177371cc74a33351d), running `bitcoin-qt.exe`, which was built with MSVC, causes a terminal window open along with the GUI.
This PR fixes such behavior. See Microsoft [docs](https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-160).
It is still possible to use the `-printtoconsole` option for debug builds.
ACKs for top commit:
sipsorcery:
tACK 9edd713c184bd6b92ff7862d0df8f1a89062e9d3.
Tree-SHA512: 02f2874b13e484f98344f6a7e3b01fa82a78a39865787c77bd674ead22a84a7f98a1849ccad26bd2b8c8603b3e29dcc1633b0ad731ce7d61be2d6b1f9584839c
|
|
Qt5.12.11 binaries
e25ea54dbfaf1c8ddc762a9a81bd5b761a3b8c73 Update msvc and appveyor builds to use Qt5.12.11 binaries. (Aaron Clauson)
Pull request description:
Synchronises the Qt version used in the msvc and Appveyor builds with #22054.
I needed to use switch to the `Visual Studio 2019 Preview` Appveyor image because the compiler version on the non-preview image is too far behind and I had difficulty building a compatible Qt version for it. Once the main Appveyor `Visual Studio 2019` image reaches version `16.10.1` it can be used.
ACKs for top commit:
hebasto:
ACK e25ea54dbfaf1c8ddc762a9a81bd5b761a3b8c73
Tree-SHA512: c5e8dcafa342df7cd8ff7c349a8186bee4cdf7fd748c5d94039e30698775058bae8099dd75a50a5079f3cbb5251e695be187bae615159e3cd45054a972c4e6bd
|
|
as we are about the change the behavior sufficiently that when we
have multiple disadvantaged networks and a small number of peers
under test, the number of protected peers per network can be different.
|
|
to compare and sort peer eviction candidates by the
passed-in is_local (localhost status) and network
arguments, and by longest uptime.
|
|
|
|
in ProtectEvictionCandidatesByRatio()
per current style guide in doc/developer-notes.md
|
|
|
