8008ef770f3d0b14d03e22371314500373732143 qt: unlock wallet "OK" button bugfix (Michael Dietz)
Pull request description:
When trying to send a transaction from an encrypted wallet, the ask
passphrase dialog would not allow the user to click the "OK" button
and proceed. Therefore it was impossible to send a transaction
through the gui. It was not enabling the "OK" button after the
passphrase was entered by the user, because it was using the same
form validation logic as the "Change passphrase" flow.
I reported this in a comment in https://github.com/bitcoin-core/gui/issues/136. But then I realized this seems to be a flat out bug.
ACKs for top commit:
MarcoFalke:
review ACK 8008ef770f3d0b14d03e22371314500373732143
hebasto:
ACK 8008ef770f3d0b14d03e22371314500373732143, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: cc09b34c7f3aea09729e1c7ccccff05dc11fec56fee2ad369f2d862979572b1edd8b7e738ffe6e91d35d071b819b0c3e0f5d48bf5e27427a80af4a28893f8aaf
b6121edf70a8d50fd16ddbba0c3168e5e49bfc2e swapped "is" for "==" in literal comparison (Tyler Chambers)
Pull request description:
In Python 3.8+ literal comparisons using "is" instead of "==" produce a SyntaxWarning [source](https://docs.python.org/3.8/whatsnew/3.8.html#changes-in-python-behavior).
I checked the entire devtools directory, this seems to be the only occurrence.
This is a small fix, but removes the SyntaxWarning.
Fixes: #20338
ACKs for top commit:
hebasto:
re-ACK b6121edf70a8d50fd16ddbba0c3168e5e49bfc2e, only squashed since my [previous](https://github.com/bitcoin/bitcoin/pull/20346#pullrequestreview-525934568) review.
practicalswift:
re-ACK b6121edf70a8d50fd16ddbba0c3168e5e49bfc2e: patch still looks correct
theStack:
utACK b6121edf70a8d50fd16ddbba0c3168e5e49bfc2e
Tree-SHA512: 82a43495d6552fbaa3b02b58f0930b049d27aa937fe44b47714e3c059f844cc494de20674557371cbccf24fb8873ecb7376fb965ae326847eed2b855ed2d59c6
174f58c1857468252a8b9214abd187fa296e883c Add link to NetBSD release (Marnix)
Pull request description:
For consistency with other Build Guides, like `doc/build-freebsd.md` & `doc/build-openbsd.md`
ACKs for top commit:
theStack:
Code-review ACK 174f58c1857468252a8b9214abd187fa296e883c
vincenzopalazzo:
ACK 174f58c185
Tree-SHA512: 08297aac82ee8fab2bbcb486b13b9c6ca12fb4fba573e9979e94204bd7340c2d13f1e54e07b314498603c291c25e29f2e89141ee150478951f699772538b709c
5dc6d9207778c51c10c16fac4b3663bc7905bafc test: make BIP157 messages default-constructible (MESSAGEMAP compatibility) (Sebastian Falbesoner)
71e4cfefe765c58937b3fd3125782ca8407315d2 test: p2p: add missing BIP157 message types to MESSAGEMAP (Sebastian Falbesoner)
Pull request description:
The script [message-capture-parser.py](https://github.com/bitcoin/bitcoin/blob/master/contrib/message-capture/message-capture-parser.py) currently doesn't support parsing the BIP157 messages `getcfilters`, `getcfheaders` and `getcfcheckpt`, e.g.
```
$ ./contrib/message-capture/message-capture-parser.py msgs_recv.dat
...
WARNING - Unrecognized message type b'getcfcheckpt' in /home/thestack/bitcoin/msgs_recv.dat
...
```
This PR fixes this by adding the missing message type mappings to the [`MESSAGEMAP`](225e5b57b2/test/functional/test_framework/p2p.py (L95-L127)) in the test framework and add default-constructors for the corresponding `msg_`... classes.
Without the second commit, the following error message would occur:
```
File "/home/thestack/bitcoin/./contrib/message-capture/message-capture-parser.py", line 141, in process_file
msg = MESSAGEMAP[msgtype]()
TypeError: __init__() missing 2 required positional arguments: 'filter_type' and 'stop_hash'
```
ACKs for top commit:
dunxen:
tACK [5dc6d92](5dc6d92077)
Tree-SHA512: d656c4d38a856373f01d7c293ae7d2b27378a9fc248048ebf2a64725ef8b498b3ddf4f420704abdb20d0c68ca548f1777602c5e73b66821a20c97ae618f1d63f
faac67cab02a755b0ce67716c5e5889432b13b83 test: Fix intermittent race in p2p_unrequested_blocks.py (MacroFake)
Pull request description:
Disconnect may also result in an `OSError`, not only an `AssertionError`. Instead of maintaining a dead code path and enumerating disconnect reasons, just assume disconnection happens every time.
ACKs for top commit:
jamesob:
Code review ACK faac67cab0
Tree-SHA512: d2cec003168e421a5faed275cb2e1ef9fc63f9e8514f41d21da17e8964c79e5b453ccd72cd7ec62805f45293cf877be5bc8124ae98a515c0aa42d6e053409653
11e79084845a78e2421ea3abafe0de5a54ca2bde prevector: only allow trivially copyable types (Martin Leitner-Ankerl)
Pull request description:
prevector uses `memmove` to move around data, that means it can only be used with types that are trivially copyable. That implies that the types are trivially destructible, thus the checks for `is_trivially_destructible` are not needed.
ACKs for top commit:
w0xlt:
ACK 11e7908484
MarcoFalke:
review ACK 11e79084845a78e2421ea3abafe0de5a54ca2bde 🏯
ajtowns:
ACK 11e79084845a78e2421ea3abafe0de5a54ca2bde -- code review only
Tree-SHA512: cbb4d8bfa095100677874b552d92c324c7d6354fcf7adab2ed52f57bd1793762871798b5288064ed1af2d2903a0ec9dbfec48d99955fc428f18cc28d6840dccc
1df42bc262d994c30d390ea73b232b8d2548899e test: compare `/mempool/info` response with `getmempoolinfo` RPC (brunoerg)
Pull request description:
This PRs compares `/mempool/info` REST response with `getmempoolinfo` RPC in `interface_rest.py`.
Similar to #24936 and #24797.
ACKs for top commit:
theStack:
ACK 1df42bc262d994c30d390ea73b232b8d2548899e
Tree-SHA512: 2de36d70fa61612e7976f875e55f98e78b1cdb909b48cff18e6a70c55eda34b799e210bcd55361ea947388b7778d867290a73be4f799bb36afd65423ad49c487
7fd0860d12da723a228ddd3c9fb905380eb8b379 Bugfix: configure: Define defaults for enable_arm_{crc,shani} (Luke Dashjr)
Pull request description:
Fix for #17398 and #24115
Trivial, mostly for consistency (you'd have to *try* to break this)
ACKs for top commit:
pk-b2:
ACK 7fd0860d12
seejee:
ACK 7fd0860d12
vincenzopalazzo:
ACK 7fd0860d12
Tree-SHA512: 51c389787c369f431ca57071f03392438bff9fd41f128c63ce74ca30d2257213f8be225efcb5c1329ad80b714f44427d721215d4f848cc8e63060fa5bc8f1f2e
bdc6881e2f796f4a9a5873826219e24f17a96a7c wallet: Change log interval to use `steady_clock` (w0xlt)
Pull request description:
This refactors the log interval variables to use `steady_clock` as it is best suitable for measuring intervals.
ACKs for top commit:
laanwj:
This makes sense. Code review ACK bdc6881e2f796f4a9a5873826219e24f17a96a7c
dunxen:
Code review ACK bdc6881
Tree-SHA512: 738b4aa45cef01df77102320f83096a0a7d0c63d7fcf098a8c0ab16b29453a87dc789c110105590e1e215d03499db1d889a94f336dcb385b6883c8364c9d39b7
3258bad996262792ba77573d6080dafa3952929c changes color of skipped functional tests (Jacob P. Fickes)
Pull request description:
changes the color of skipped functional tests (currently grey and can be hard to read/invisible on dark backgrounds) to yellow.
resolves#24791
ACKs for top commit:
theStack:
Tested ACK 3258bad996262792ba77573d6080dafa3952929c
jarolrod:
Tested ACK 3258bad996
Tree-SHA512: 3fe5ae0d3b4902b2b6bda6e89ab780feb8bf4b7cb1ce7e8467057b94a1e0a26ddeaf3cac0bc19b06ef10d8bccaac9c495029d42740fbedab8fb0d5fdd7d02eaf
fa4652ce5995ace831b6a4d3125bfcac9563ff6f Pass lifetimebound reference to SingleThreadedSchedulerClient (MacroFake)
Pull request description:
Currently a pointer is passed, which is confusing and requires run-time asserts to avoid nullptr dereference.
All call sites can pass a reference, so do that. Also mark it LIFETIMEBOUND to avoid call sites passing a temporary. Also, unrelated cleanup in touched lines.
ACKs for top commit:
pk-b2:
ACK fa4652ce59
jonatack:
Code review ACK fa4652ce5995ace831b6a4d3125bfcac9563ff6f rebased to master, debug build, unit tests
vincenzopalazzo:
ACK fa4652ce59
Tree-SHA512: cd7ec77347e195d659b8892d34c1e9644d4f88552a4d5fa310dc1756eb27050a99d3098b0b0d27f8474230f82c178fd9e22e7018d8248d5e47a7f4caad395e25
e5485e8e4be7f2ee0671f58c3dcce35c68ba0ee0 test, bench: make prevector and checkqueue swap member functions noexcept (Jon Atack)
abc1ee509025d92db5311c3f5df3b61c09cad24f validation: make CScriptCheck and prevector swap member functions noexcept (Jon Atack)
Pull request description:
along with those seen elsewhere in the codebase (prevector and checkqueue units/fuzz/bench).
A swap must not fail; when a class has a swap member function, it should be declared noexcept.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c84-a-swap-function-must-not-fail
ACKs for top commit:
pk-b2:
ACK e5485e8e4b
w0xlt:
ACK e5485e8e4b
Tree-SHA512: c82359d5e13f9262ce45efdae9baf71e41ed26568e0aff620e2bfb0ab37a62b6d56ae9340a28a0332c902cc1fa87da3fb72d6f6d6f53a8b7e695a5011f71f7f1
bef61496ab5e12e38ac5794cd0836723af070ab5 test: compare `/mempool/contents` response with `getrawmempool` RPC (brunoerg)
5bc5cbaf310f60e89c72e8ecf3f6187c85499027 doc: add reference to `getrawmempool` RPC in `/mempool/contents` REST doc (brunoerg)
Pull request description:
This PR is similar to #24797, it compares `/mempool/contents` REST response with `getrawmempool` RPC (verbose=True) since they use the same `MempoolToJSON` function.
Also, adds a reference to `getrawmempool` RPC help to get details about the fields from `/mempool/contents`.
ACKs for top commit:
0xB10C:
ACK bef6149
Tree-SHA512: b7e9e9c765ee837986ba167b9234a9b95c9ef0a9ebcc2a03d50f6be6d3aba1480bd77c78111d95df1e4023cde6dfc64bf1e7908d9e5b6f96ca46b76611a4a9b4
fad6d4f952373690ef16ce27b0926c0ab762066a Remove not needed ArithToUint256 roundtrips in tests (MarcoFalke)
fa456ccb2287b2a1a4eb7224b424f12fe59302e9 Remove duplicate static_asserts (MarcoFalke)
Pull request description:
No need to go from `arith_uint256`->`uint256` when a `uint256` can be constructed right away.
ACKs for top commit:
laanwj:
Code review ACK fad6d4f952373690ef16ce27b0926c0ab762066a
Tree-SHA512: bea901ea5904bf61a0dadf7168c6b126f7e62ff1180d4aa72063c28930a01a8baa57ab0d324226bd4de72fb59559455c29c049d90061f888044198aae1426dcb
3ec6504a2e5b4afb7a2719a82191e0b96fe23214 qt: Do not use `QKeyEvent` copy constructor (Hennadii Stepanov)
Pull request description:
This PR is preparation for [Qt 6](https://github.com/bitcoin/bitcoin/pull/24798), and it fixes an experimental build with Qt 6.2.4 as copying of `QEvent` has been [disabled](19f9b0d5f5) in Qt 6.0.0.
ACKs for top commit:
w0xlt:
tACK 3ec6504a2e on Ubuntu 21.10, Qt 5.15.2
shaavan:
reACK 3ec6504a2e5b4afb7a2719a82191e0b96fe23214
Tree-SHA512: 583a9dad0c621d9f02f77ccaa9f55ee79e12e3c47f418911ef2dfe0de357d772d1928ae3ec19b6f0c0674da858bab9d4542a26cc14b06ed921370dfeabd1c194
99a6b699cd650f13d7200d344bf5e2d4b45b20ac Fix race condition for SetBannedSetDirty() calls (Hennadii Stepanov)
83c76467157bbca023bffda0f0bc2f01eb76a040 Avoid calling BanMan::SweepBanned() twice in a row (Hennadii Stepanov)
33bda6ab87cc1b569e96da337296eb3e9ce6db1a Fix data race condition in BanMan::DumpBanlist() (Hennadii Stepanov)
5e20e9ec3859205c220867ca49efb752b8edaacc Prevent possible concurrent CBanDB::Write() calls (Hennadii Stepanov)
Pull request description:
This PR split from bitcoin/bitcoin#24097 with some additions. This makes the following switch from `RecursiveMutex` to `Mutex` a pure refactoring.
See details in commit messages.
ACKs for top commit:
w0xlt:
reACK 99a6b69
shaavan:
ACK 99a6b699cd650f13d7200d344bf5e2d4b45b20ac
Tree-SHA512: da4e7268c7bd3424491f446145f18af4ccfc804023d0a7fe70e1462baab550a5e44f9159f8b9f9c7820d2c6cb6447b63883616199e4d9d439ab9ab1b67c7201b
f13e642c831c5689cb2bb7f5c4f9cb4c0c03ef21 build: Disable valgrind when building zeromq package in depends (Hennadii Stepanov)
b970f03beae0f3ae6a796f0e3b97732fc579f6aa build: Disable libbsd when building zeromq package in depends (Hennadii Stepanov)
77899991b1e29a45bc377b21330148cb7cc08923 build: Update netbsd_kevent_void.patch (Hennadii Stepanov)
Pull request description:
Since v4.3.3 (068385c951) `libzmq` uses `libbsd` by default.
This PR disables `libbsd` explicitly, as it's not a part of our depends. Zeromq will fallback to its internal `strlcpy` implementation.
Otherwise, on systems with installed `libbsd-dev` package the `zeromq` package build system erroneously detects `libbsd` package from the host system:
```diff
--- a/libzmq.pc
+++ b/libzmq.pc
@@ -8,5 +8,5 @@
Version: 4.3.4
Libs: -L${libdir} -lzmq
Libs.private: -lpthread
-Requires.private:
+Requires.private: libbsd
Cflags: -I${includedir}
```
This causes the `configure` fails to detect the `zeromq` package:
```
configure: WARNING: libzmq version 4.x or greater not found, disabling
```
---
Other minor improvements:
- fixed `netbsd_kevent_void.patch` offset
- disabled valgrind as it's used in unit tests which we do not run:
```diff
--- a/zmq-configure-output
+++ b/zmq-configure-output
@@ -119,11 +119,6 @@
checking whether the g++ -m64 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
-checking for valgrind... valgrind
-checking for Valgrind tool memcheck... memcheck
-checking for Valgrind tool helgrind... helgrind
-checking for Valgrind tool drd... drd
-checking for Valgrind tool exp-sgcheck... exp-sgcheck
checking linker version script flag... --version-script
checking if version scripts can use complex wildcards... yes
checking for working posix_memalign... yes
```
ACKs for top commit:
fanquake:
ACK f13e642c831c5689cb2bb7f5c4f9cb4c0c03ef21
Tree-SHA512: d4c86d4a841eb6e7c32157e84972243072f905496c2a4c14ec6f6ab4216df6695cbf29baa2233ce27eaede35d1e250ad2f9975b16f570d01509f0c5da4597cad
6897c4bdf51a4aa74320ebfffa9467db14670109 build: patch depends zeromq to fix building on NetBSD Current (fanquake)
ce6dd2f1a2e2c56d86d00e0eeec34c9982017416 zeromq 4.3.4 (fanquake)
Pull request description:
This is a prerequisite for #23955. It updates zeromq to the latest available version, and adds a patch, [that I've sent upstream](https://github.com/zeromq/libzmq/pull/4326), to fix building on NetBSD Current (10).
ACKs for top commit:
hebasto:
ACK 6897c4bdf51a4aa74320ebfffa9467db14670109, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: d05d9753630faebe842e1ca70c8c4af660a38e7331a9d95e84df3a3b14564c5118ca41c4fc49fb71dfee563b63e1014e5a3f8874d652e26de59e8e188a12970e
c62d763fc313585d79ad833c9d729f6acf2652aa Necessary improvements to make configure work without libevent installed (Perlover)
091ccc38c2e589b649648cbcc99aca4802f98775 The evhttp_connection_get_peer function from libevent changes the type of the second parameter. Fixing the problem. (Perlover)
Pull request description:
The second parameter of evhttp_connection_get_peer in libevent already has type as `const char **`
The compilation of bitcoind with the fresh libevent occurs errors
Details: https://github.com/bitcoin/bitcoin/issues/23606
ACKs for top commit:
laanwj:
Code review ACK c62d763fc313585d79ad833c9d729f6acf2652aa
luke-jr:
tACK c62d763fc313585d79ad833c9d729f6acf2652aa
Tree-SHA512: d1c8062d90bd0d55c582dae2c3a7e5ee1b6c7ca872bf4aa7fe6f45a52ac4a8f59464215759d961f8efde0efbeeade31b08daf9387d7d50d7622baa1c06992d83
64e1ddd255771e57a88a20f07dbde04a83bf0c75 log: call LogPrint only once with time data samples (Martin Zumsande)
Pull request description:
When timedata samples are logged, `LogPrint()` is currently invoked multiple times on the same log entry.
This can lead to chaos in the log when other threads log concurrently, as in this example which motivated this PR:
```
2021-09-20T00:28:57Z -48 -26 -11 -8 -6 Addrman checks started: new 37053, tried 83, total 37136
2021-09-20T00:28:57Z -3 -1 -1 -1 -1 +0 | nTimeOffset = -3 (+0 minutes)
```
Fix this by building the log message in a string and logging it one `LogPrint()` call. I also changed the wording slightly so that it becomes understandable what is being logged, example:
```
2021-09-21T21:03:24Z time data samples: -43 -18 -12 -4 -1 -1 +0 +0 +268 | median offset = -1 (+0 minutes)
```
ACKs for top commit:
jnewbery:
Tested ACK 64e1ddd255
laanwj:
Tested ACK 64e1ddd255771e57a88a20f07dbde04a83bf0c75, new message lgtm
Tree-SHA512: ffb7a93166cc8fd6a39200b9e03a9d1e8e975b7ded822ccddd015f553258b991162a5cb867501f426d3ebcfef4f32f0e06e17b18e6b01486b967595d102f8379
cc3044ccdbefa9fae58d1762477e377883b39c5e fix misleading comment about call to non-existing function (pox)
Pull request description:
The comment seems to be describing the subsequent call to `SyncTransaction` but refers to it as `SyncNotifications`, which is not any function currently in the codebase.
It's best to just remove the "what" aspect of the comment and focus on the "why", which also reduces the risk of similar documentation errors in the future, in case the function ever gets renamed, for example.
ACKs for top commit:
laanwj:
ACK cc3044ccdbefa9fae58d1762477e377883b39c5e
Tree-SHA512: 882ff17836ef585a603dc504f3dd21f56f682e49b28a0998f23fd16025826fbb083b7978db3ee70d0e0ff2c86fd6c3fd99a2361e5d45c765fdc5822c5f14c0a7
198fff88f385e090b57a0ee902719bcc22a6b86b GUI: Define MAX_DIGITS_BTC for magic number in BitcoinUnits::format (Luke Dashjr)
Pull request description:
A magic number snuck in with https://github.com/bitcoin/bitcoin/pull/16432
ACKs for top commit:
hebasto:
ACK 198fff88f385e090b57a0ee902719bcc22a6b86b, I have reviewed the code and it looks OK, I agree it can be merged.
kristapsk:
utACK 198fff88f385e090b57a0ee902719bcc22a6b86b
Tree-SHA512: 78dc23c2ae61bac41e5e34eebf57274599cb2ebb0b18d46e8a3228d42b256a1bc9bb17091c748f0f692ef1c4c241cfbd3e30a12bcd12222a234c1a9547ebe786
2ea62cae483b764e30f61c06d8ac65755bbd864c Improve docs about feeler connections (Gleb Naumenko)
Pull request description:
"feeler" and "test-before-evict" are two different strategies suggest in [Eclipse Attacks on Bitcoin’s Peer-to-Peer Network](https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-heilman.pdf). In our codebase, we use `ConnType::FEELER` to implement both.
It is confusing, up to the point that our documentation was just incorrect.
This PR:
- ~clarifies this aspect by renaming "ConnType::FEELER" to "ConnType::PROBE", meaning that this connections only probes that the node is operational, and then disconnects.~
- fixes the documentation
ACKs for top commit:
amitiuttarwar:
ACK 2ea62cae48. thank you!
practicalswift:
ACK 2ea62cae483b764e30f61c06d8ac65755bbd864c
Tree-SHA512: c9c03c09eefeacec28ea199cc3f697b0a98723f2f849f7a8115edc43791f8165e296e0e25a82f0b5a4a781a7de38c8954b48bf74c714eba02cdc21f7460673e5
## Issue being fixed or feature implemented
Client version string is inconsistent. Building `v20.0.0-beta.8` tag
locally produces binaries that report `v20.0.0-beta.8` version but
binaries built in guix would report
`v20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5ee` instead. Building
any commit after `v20.0.0-beta.8` locally would result in versions like
`v20.0.0rc1-8c94153d2497` which is close but it's still yet another
format. And both versions with `rc1` in their names are confusing cause
you'd expect them to mention `beta.8` instead maybe (or is it just me?
:D ).
## What was done?
Change it so that the version string would look like this:
on tag: ~`v20.0.0-beta.8-dev` or `v20.0.0-beta.8-gitarc`~
`v20.0.0-beta.8`
post-tag: ~`v20.0.0-beta.8-1-gb837e08164-gitarc`~
`v20.0.0-beta.8-1-gb837e08164`
post-tag format is
`recent tag`-`commits since that tag`-`g+12 chars of commit hash`-`dirty
(optional)` ~-`dev or gitarc`~
~`dev`/`gitarc` suffixes should help avoiding confusion with the release
versions and they also indicate the way non-release binaries were
built.~
Note that release binaries do not use any of this, they still use
`PACKAGE_VERSION` from `configure` like before.
Also, `CLIENT_VERSION_RC` is no longer used in this setup so it was
removed.
Few things aren't clear to me yet:
1. Version bump in `configure.ac` no longer affects the reported version
(unless it's an actual release). Are there any downsides I might be
missing?
2. Which tag should we use on `develop` once we bump version in
configure? `v21.0.0-init`? `v21.0.0-alpha1`?
3. How is it going to behave once `merge master back into develop` kind
of PR is merged? E.g. say `develop` branch is on `v21.0.0-alpha1` tag
and we merge v20.1.0 from `master` back into it. Will this bring
`v20.1.0` release tag into `develop`? Will it become the one that will
be used from that moment? If so we will probably need another tag on
`develop` every time such PR is merged e.g. `v21.0.0-alpha2` (or
whatever the next number is).
Don't think these are blockers but would like to hear thoughts from
others.
## How Has This Been Tested?
Built binaries locally, built them using guix at a specific tag and at
some commit on top of it.
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
We should avoid return by reference; especially return by reference with
a bool flag indicating validity.
## What was done?
Instead we use a std::optional
## How Has This Been Tested?
Unit tests pass
## Breaking Changes
Should be none
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
---------
Co-authored-by: Konstantin Akimov <knstqq@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
## Issue being fixed or feature implemented
Implement a new code-singing certificate for windows.
Previously we used a certificate issued by DigiCert, however that
certificate recently expired. A renewed certificate would cost roughly
$200/year at the cheapest CAs and $370/year with DigiCert. EV
certificates are relatively novel types of certificates that start out
with positive reputation, reducing smart screen popups for users. EV
certificates start at $270/year.
As a result we had (/have) 4 options:
1. Get a new code signing certificate from a trusted CA
- - Pro: Certificate gains reputation over time in smart screen and
binaries are signed
- - Pro: Shows "Verified Publisher" and "Dash Core Group Inc" on install
- - Con: Costs, feels manipulative to pay at least $600 simply for
someone to sign a certificate
2. Get a new EV code signing certificate
- - Pro: Certificate starts with good reputation and gains reputation
over time
- - Con: Even greater costs for a signature that says that we are from
Dash Core Group
3. Continue signing with the expired certificate
- - Con: This is, it has been discovered, a terrible idea and these
binaries are treated worse than unsigned binaries
4. Deliver unsigned windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: Easy, is what it says on the tin
- - Con: Binaries are completely unsigned, could be tampering or
corruption issues that go undetected
- - Con: Will visibly state "Unknown Publisher"
5. Deliver self-signed windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: *Possibility* that certificate will gain reputation over time
as users download binaries signed by it. It may also be that only
certificates issued by a CA will gain reputation over time.
- - Pro: Binaries are still signed
- - Pro: Users have the option to import certificate into keychain to
remove "Unknown Publisher"
- - Pro: In limited testing, install is sometimes is treated better than
unsigned, otherwise is treated the same
- - Con: may appear sketchy, as Root CA is not a trusted Root CA
- - Con: will display "Unknown Publisher" to most users
- - Con: greater potential uncertainty around future changes to
treatment of self signing systems
Based on the above discussion and testing, the best route currently is
option 5; that is what this PR implements. In the future it may make
sense to move towards a codesigning certificate issued by a trusted CA.
The root certificate authority has the following information
with a sha256 fingerprint of `46 84 FF 27 11 D7 C8 C5 BB FA D1 55 41 B3
F0 43 77 97 AC 67 4C 32 19 AE B4 E7 15 11 1F BB 42 A0`
The code signing certificate is issued by the root CA, has a common name
of "Dash Core Windows Signing" and a sha256 fingerprint of `1A 09 54 6E
D3 81 E9 FC AD 62 44 32 35 40 39 FF 5F A7 30 0E 5E 03 C4 E0 96 5A 62 AA
19 2B 79 EE`. This certificate is only authorized for the purpose of
code signing.
## What was done?
## How Has This Been Tested?
Multiple users installing binaries of type 1,3,4 and 5.
## Breaking Changes
This new windows signing certificate should be documented in the release
notes.
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- - [x] I have performed a self-review of my own code
- - [ ] I have commented my code, particularly in hard-to-understand
areas
- - [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- - [ ] I have made corresponding changes to the documentation
- - [x] I have assigned this pull request to a milestone _(for
repository code-owners and collaborators only)_
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEKVkDYuyHioH9PCArUlJ77avoeYQFAmWfAbUACgkQUlJ77avo
eYTSCBAAuDEoWABdonIMs/4RaYP+DGTULltRu9CHBAqYuksXrl/4iV0r17DPSWWW
L/5vLNAUTI47Tsa7R45ZPb0hR8VPMBkvxTQipKBYK7vZpwefcR4VOprEBJJ0Bl3g
ZHtAVjZbcANEIAW3SlaiOgWbxWGKfDyM7gN3aNfoidMFBefbcYKEttuAGCnktWRI
Y3eLMGPCpxOVB0O1nLU+pzwixAWXOeVChiK31ecFfQrF3JmUc12yiFUI+OJTogg4
0G2GMIQYHiVwclj8hSWT/yZfjcyxXdLYqkmH4Nr5mye39hRI2aUQEkmkYOy8pjcB
ykKLg8JpUg/zg6GSuS6mFJnd5NHq5iSBxSRHPfR8xij1xFpmdgAaNCw4/6j9PEXB
l8cfuJ7hgX3yX09L4p2E4t7MYpM8igaenAIWAK37hmKs1WADBmaj/nf6ThKhjvzI
2GR0FOzm6Is36KYvdUQJDE0g70g31SvGy+qjlcK49MtX6BvecYt+dg8AaNZ5FIn7
d1kFI4NXM6JX2WdiHMenz5d+oFYRS/P1sXjQ1wtl9HSkiZQQkEBbgiWXfh+EXjpW
fNc8cej2LLCNZlhVcpffF8UaINsMTZVQsEGWGInjSi5eCs/YNrqL8XDdC/8mmZCu
cNvp0QBtQ+4lpbUSdhFUdgic0MRCsdeHuYIBfvPJN9tl8McbknA=
=kL6E
-----END PGP SIGNATURE-----
## What was done?
drop version from README.md which is not really useful.
And we will care about one less thing during each release
## Breaking Changes
N/A
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
## Issue being fixed or feature implemented
Implement a new code-singing certificate for windows.
Previously we used a certificate issued by DigiCert, however that
certificate recently expired. A renewed certificate would cost roughly
$200/year at the cheapest CAs and $370/year with DigiCert. EV
certificates are relatively novel types of certificates that start out
with positive reputation, reducing smart screen popups for users. EV
certificates start at $270/year.
As a result we had (/have) 4 options:
1. Get a new code signing certificate from a trusted CA
- - Pro: Certificate gains reputation over time in smart screen and
binaries are signed
- - Pro: Shows "Verified Publisher" and "Dash Core Group Inc" on install
- - Con: Costs, feels manipulative to pay at least $600 simply for
someone to sign a certificate
2. Get a new EV code signing certificate
- - Pro: Certificate starts with good reputation and gains reputation
over time
- - Con: Even greater costs for a signature that says that we are from
Dash Core Group
3. Continue signing with the expired certificate
- - Con: This is, it has been discovered, a terrible idea and these
binaries are treated worse than unsigned binaries
4. Deliver unsigned windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: Easy, is what it says on the tin
- - Con: Binaries are completely unsigned, could be tampering or
corruption issues that go undetected
- - Con: Will visibly state "Unknown Publisher"
5. Deliver self-signed windows binaries
- - Pro: Binary will gain reputation over time as users download it
- - Pro: *Possibility* that certificate will gain reputation over time
as users download binaries signed by it. It may also be that only
certificates issued by a CA will gain reputation over time.
- - Pro: Binaries are still signed
- - Pro: Users have the option to import certificate into keychain to
remove "Unknown Publisher"
- - Pro: In limited testing, install is sometimes is treated better than
unsigned, otherwise is treated the same
- - Con: may appear sketchy, as Root CA is not a trusted Root CA
- - Con: will display "Unknown Publisher" to most users
- - Con: greater potential uncertainty around future changes to
treatment of self signing systems
Based on the above discussion and testing, the best route currently is
option 5; that is what this PR implements. In the future it may make
sense to move towards a codesigning certificate issued by a trusted CA.
The root certificate authority has the following information
with a sha256 fingerprint of `46 84 FF 27 11 D7 C8 C5 BB FA D1 55 41 B3
F0 43 77 97 AC 67 4C 32 19 AE B4 E7 15 11 1F BB 42 A0`
The code signing certificate is issued by the root CA, has a common name
of "Dash Core Windows Signing" and a sha256 fingerprint of `1A 09 54 6E
D3 81 E9 FC AD 62 44 32 35 40 39 FF 5F A7 30 0E 5E 03 C4 E0 96 5A 62 AA
19 2B 79 EE`. This certificate is only authorized for the purpose of
code signing.
## What was done?
## How Has This Been Tested?
Multiple users installing binaries of type 1,3,4 and 5.
## Breaking Changes
This new windows signing certificate should be documented in the release
notes.
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- - [x] I have performed a self-review of my own code
- - [ ] I have commented my code, particularly in hard-to-understand
areas
- - [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- - [ ] I have made corresponding changes to the documentation
- - [x] I have assigned this pull request to a milestone _(for
repository code-owners and collaborators only)_
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEKVkDYuyHioH9PCArUlJ77avoeYQFAmWfAbUACgkQUlJ77avo
eYTSCBAAuDEoWABdonIMs/4RaYP+DGTULltRu9CHBAqYuksXrl/4iV0r17DPSWWW
L/5vLNAUTI47Tsa7R45ZPb0hR8VPMBkvxTQipKBYK7vZpwefcR4VOprEBJJ0Bl3g
ZHtAVjZbcANEIAW3SlaiOgWbxWGKfDyM7gN3aNfoidMFBefbcYKEttuAGCnktWRI
Y3eLMGPCpxOVB0O1nLU+pzwixAWXOeVChiK31ecFfQrF3JmUc12yiFUI+OJTogg4
0G2GMIQYHiVwclj8hSWT/yZfjcyxXdLYqkmH4Nr5mye39hRI2aUQEkmkYOy8pjcB
ykKLg8JpUg/zg6GSuS6mFJnd5NHq5iSBxSRHPfR8xij1xFpmdgAaNCw4/6j9PEXB
l8cfuJ7hgX3yX09L4p2E4t7MYpM8igaenAIWAK37hmKs1WADBmaj/nf6ThKhjvzI
2GR0FOzm6Is36KYvdUQJDE0g70g31SvGy+qjlcK49MtX6BvecYt+dg8AaNZ5FIn7
d1kFI4NXM6JX2WdiHMenz5d+oFYRS/P1sXjQ1wtl9HSkiZQQkEBbgiWXfh+EXjpW
fNc8cej2LLCNZlhVcpffF8UaINsMTZVQsEGWGInjSi5eCs/YNrqL8XDdC/8mmZCu
cNvp0QBtQ+4lpbUSdhFUdgic0MRCsdeHuYIBfvPJN9tl8McbknA=
=kL6E
-----END PGP SIGNATURE-----
9b4fa0af40cd88ed25dd77962235fbf268bdcaa7 net: Print error message if -proxy is specified without arguments (instead of continuing without proxy server) (practicalswift)
Pull request description:
Exit with error message if `-proxy` is specified without arguments (instead of continuing without proxy server).
Continuing without a proxy server when the end-user has specified `-proxy` may result in accidental loss of privacy. (The end-user might think he/she is using a proxy when he/she is not.)
Before this patch:
```
$ src/bitcoind -proxy
…
2020-09-23T00:24:33Z InitParameterInteraction: parameter interaction: -proxy set -> setting -listen=0
2020-09-23T00:24:33Z InitParameterInteraction: parameter interaction: -proxy set -> setting -upnp=0
2020-09-23T00:24:33Z InitParameterInteraction: parameter interaction: -proxy set -> setting -discover=0
2020-09-23T00:24:33Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
…
2020-09-23T00:24:33Z init message: Starting network threads...
```
`bitcoind` is now running *without* a proxy server (`GetProxy(…, …) == false`, `HaveNameProxy() == false`, etc.).
Note that the "-proxy set" log messages above which the end-user might interpret as "good, my traffic is now routed via the proxy".
After this patch:
```
$ src/bitcoind -proxy
Error: No proxy server specified. Use -proxy=<ip> or -proxy=<ip:port>.
$ echo $?
1
```
ACKs for top commit:
laanwj:
re-ACK 9b4fa0af40cd88ed25dd77962235fbf268bdcaa7
kristapsk:
ACK 9b4fa0af40cd88ed25dd77962235fbf268bdcaa7, I have tested the code.
hebasto:
re-ACK 9b4fa0af40cd88ed25dd77962235fbf268bdcaa7
Tree-SHA512: 4ba7a011991699a54b5bb87ec68367c681231bf5dcd36f8c89ff9ddc2e8d29df453817b7e362597e652ad6b341a22b7274be0fd78d435e5f0fd8058e5221c4ce
916d3596c493fec44da86aeb92b61eafeea0b596 help: Generate checkpoint height from chainparams (Luke Dashjr)
Pull request description:
Not sure if this is worth putting in Core, but might as well until checkpoints are removed entirely.
ACKs for top commit:
laanwj:
re-ACK 916d3596c493fec44da86aeb92b61eafeea0b596
Tree-SHA512: d8eb26b570ee730fdd75ca916507134db5f2f68987a911e33544b7f1c9ccfd1c76b9c9db63056971956b6daf16910f17ecfc197481c2f7b0773afdfbf7d381cf
d11020019a0c93dcc56859cdfcd9f0c6a777424f Add OpenBSD instructions for building the Qt GUI (grubles)
Pull request description:
Using OpenBSD as a desktop OS is prevalent enough IMO to warrant updating the documentation for building the GUI.
ACKs for top commit:
fanquake:
ACK d11020019a0c93dcc56859cdfcd9f0c6a777424f - looks fine. Have not tested.
Tree-SHA512: a8078334fdd35438bcf87c3f5eae851c2a1ce961eb48ae50770bf2c556489da86b6ee198fe9fb732dcaddb2e0f2f4f55a3126971aae8f7d4e2e320dbb024e204
d3e8adfada889a3c9fba930086eda609509aca07 util: remove c-string interfaces for DecodeBase58{Check} (Sebastian Falbesoner)
Pull request description:
This micro-PR gets rid of base58 function interfaces that are redundant in terms of c-string / std::string variants; the c-string interface for `DecodeBase58Check` is completely unused outside the base58 module, while the c-string interface for `DecodeBase58` is only used in unit tests, where an implicit conversion to std::string is not problematic.
ACKs for top commit:
practicalswift:
ACK d3e8adfada889a3c9fba930086eda609509aca07 -- patch looks correct
laanwj:
Code review ACK d3e8adfada889a3c9fba930086eda609509aca07
Tree-SHA512: 006a4a1e23b11385f60820c188b8e6b1634a182ca36e29a6580f72150214c65a3fdb273ec439165f26ba88a42d2bf5bab1cf3666a9eaee222fb4e1c00aeba433
1ccb9f30c040daf688f89f0d63e9f5e7b131d193 Move Win32 defines to configure.ac to ensure they are globally defined (Luke Dashjr)
Pull request description:
#9245 no longer needs this, since the main `_WIN32_WINNT` got bumped by something else.
So rather than just lose it, might as well get it merged in independently.
I'm not aware of any practical effects, but it seems safer to use the same API versions everywhere.
ACKs for top commit:
fanquake:
ACK 1ccb9f30c040daf688f89f0d63e9f5e7b131d193 - checked that the binaries produced are the same.
Tree-SHA512: 273e9186579197be01b443b6968e26b9a8031d356fabc5b73aa967fcdb837df195b7ce0fc4e4529c85d9b86da6f2d7ff1bf56a3ff0cbbcd8cee8a9c2bf70a244
1e58bcc9afefcf009653567c6373b4f7facba8f5 wallet: Fix clang build in Mac (Anthony Fieroni)
Pull request description:
Signed-off-by: Anthony Fieroni <bvbfan@abv.bg>
Top commit has no ACKs.
Tree-SHA512: 19312929af14dab97c37cf4547fbd6589a6de960f1a499c2118bb684240639af4b127cf8dc4d201b41d253cfbb645614a0606d4ecce29f300b10c210d38a961b
