Age | Commit message (Collapse) | Author |
|
9e111db088e4137865ae068d206c769994ea0a29 test: set a name for CI Docker containers (fanquake)
Pull request description:
Addresses one part of #16664, by making it easier to identify CI containers that are running locally. By default Docker will generate random names, like `peaceful_rubin`, with this change, we explicitly set names for all containers.
ACKs for top commit:
MarcoFalke:
ACK 9e111db088e4137865ae068d206c769994ea0a29
Tree-SHA512: 0a29ada0d8cf6b0e9ae7a35f4f6df7a3dcc448523ceaed01371124360d6e3d1bf351172104a5fb629488eeaa57994ba04134dcb83c261eb1dfd2f0d73edf5f60
|
|
b0a01299ed8cc2026e91a8dcad880b700e462cee test: Disable s390 build on travis (Wladimir J. van der Laan)
Pull request description:
Travis is consistently failing on s390 due to out of disk space issues,
which causes false positives. Disable the s390 build for now until
this is fixed some other way.
ACKs for top commit:
MarcoFalke:
ACK b0a01299ed8cc2026e91a8dcad880b700e462cee š
jonasschnelli:
ACK b0a01299ed8cc2026e91a8dcad880b700e462cee
Tree-SHA512: ae8a78fa03bc620d802e4992d46929a0a4b801b50a6066d8f093f93fc5ebbc010d221c04787cbfc75436a2c40f9292257bf85fbb251593e21afff11756b6d8d4
|
|
|
|
97aa5740c0e9ef433cbedafe689b641297b50f5e Squashed 'src/univalue/' changes from 5a58a46671..98261b1e7b (MarcoFalke)
Pull request description:
Closes #17742
ACKs for top commit:
fanquake:
ACK fad9ea8fdb0a7269a3fcc472fd948669d74f7aa7
Tree-SHA512: 6316cb0e974ee6575e2a98930203dc7d155b346d2d2fe5a322e3d8b77a87d378d31fde16ea2f90ff93736429ddb89799a26945de13ce4a20132550bbcec0a48e
|
|
Travis is consistently failing on s390 due to out of disk space issues,
which causes false positives. Disable the s390 build for now until
this is fixed some other way.
|
|
ac57859e53167f4ff3da467b616b0902c93701a9 qt: Fix deprecated QCharRef usage (Hennadii Stepanov)
Pull request description:
From Qt docs:
- [`QKeyEvent::text()`](https://doc.qt.io/qt-5/qkeyevent.html#text):
> Return values when modifier keys such as Shift, Control, Alt, and Meta are pressed differ among platforms and could return an empty string.
- [`QString::operator[]()`](https://doc.qt.io/qt-5/qstring.html#operator-5b-5d):
> **Note:** Before Qt 5.14 it was possible to use this operator to access a character at an out-of-bounds position in the string, and then assign to such a position, causing the string to be automatically resized. Furthermore, assigning a value to the returned `QCharRef` would cause a detach of the string, even if the string has been copied in the meanwhile (and the `QCharRef` kept alive while the copy was taken). These behaviors are deprecated, and will be changed in a future version of Qt.
Since Qt 5.14 this causes a `QCharRef` warning if any modifier key is pressed while the splashscreen is still displayed.
Fix #18080.
Note: Ctrl+Q will also close the spashscreen now.
ACKs for top commit:
jonasschnelli:
utACK ac57859e53167f4ff3da467b616b0902c93701a9
Tree-SHA512: a7e5559410bd05c406007ab0243f458b82d434b0543276ed331254c8d7a6b1aaa54d0b406f799b830859294975004380160f8af04ba403d3bf185d51e6784f54
|
|
2af3e16ca917acd85c2d4f709f6d486519d6af0d Qt: pass clientmodel changes from walletframe to walletviews (Jonas Schnelli)
Pull request description:
Fixes #18090
We currently don't pass `clientmodel` changes from the `walletframe` to the `walletviews` leading to possible invalid access during shutdown because all walletviews miss the nullifying of the clientmodel.
TODO: needs investigation if this is should be backported.
ACKs for top commit:
laanwj:
Good catch, code review ACK 2af3e16ca917acd85c2d4f709f6d486519d6af0d
Tree-SHA512: f8c0a114f01deac07fb311112d144f3bfc1c1882dd19e8742b372dd597d7a5d59cd0af99fc50494de2334cad98d6701675317474e40fe8820d04c058aeca1b75
|
|
d76894987d0277e8011932ab7dfd77c537f8ea6e logging: enable thread_local usage on macOS (fanquake)
Pull request description:
Now that we're building against a newer SDK (`10.14`), we should be able to enable `thread_local` usage on macOS. Have tested building and running locally, as well as cross-compiling and running the binaries on a macOS 10.14 system.
#### master 8a56f79d491271120abc3843c46e9dda44edd308
```bash
src/bitcoind -logthreadnames=1
2020-02-06T04:38:33Z [] Bitcoin Core version v0.19.99.0-8a56f79d4 (release build)
2020-02-06T04:38:33Z [] Assuming ancestors of block 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf have valid signatures.
2020-02-06T04:38:33Z [] Setting nMinimumChainWork=000000000000000000000000000000000000000008ea3cf107ae0dec57f03fe8
2020-02-06T04:38:33Z [] Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2020-02-06T04:38:33Z [] Using RdSeed as additional entropy source
```
#### this PR d76894987d0277e8011932ab7dfd77c537f8ea6e
```bash
checking for thread_local support... yes
...
src/bitcoind -logthreadnames=1
2020-02-06T04:17:49Z [net] net thread start
2020-02-06T04:17:49Z [opencon] opencon thread start
2020-02-06T04:17:49Z [dnsseed] dnsseed thread start
2020-02-06T04:17:49Z [init] init message: Done loading
2020-02-06T04:17:49Z [msghand] msghand thread start
2020-02-06T04:17:49Z [addcon] addcon thread start
...
2020-02-06T04:17:54Z [init] tor: Thread interrupt
2020-02-06T04:17:54Z [init] Shutdown: In progress...
```
From the [Xcode 8 release notes](https://developer.apple.com/library/archive/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW78)
> C++ now supports the thread_local keyword, which declares thread-local storage (TLS) and supports C++ classes with non-trivial constructors and destructors. (9001553)
ACKs for top commit:
jonasschnelli:
Tested ACK d76894987d0277e8011932ab7dfd77c537f8ea6e
nijynot:
ACK d768949
hebasto:
ACK d76894987d0277e8011932ab7dfd77c537f8ea6e
Tree-SHA512: 48f3e4104b80bd7b6aedcef10bb1957b073530130f33af7c5cb59e876ac3f5480e53d7af1c0b226d809fe9eef1add3d6c3fb6de4af174966202c6030060ea823
|
|
677fb8e92380d4deb6a3753047c01f7cf7b5af91 test: Add ubsan surpression for crc32c (Wladimir J. van der Laan)
8e68bb1ddeca504bedd40aee8492b5478a88c1e5 build: Disable msvc warning 4722 for leveldb build (Aaron Clauson)
be23949765e1b2e050574c6c2a136658a89dee5d build: MSVC changes for leveldb update (Aaron Clauson)
9ebdf047578f0da7e6578d0c51c32f55e84ac157 build: CRC32C build system integration (Wladimir J. van der Laan)
402252a8081e25f22aa1a5c60708714cf1d84ec4 build: Add LCOV exception for crc32c (Wladimir J. van der Laan)
3a037d0067c2c12a1c2c800fb85613a0a2911253 test: Add crc32c exception to various linters and generation scripts (Wladimir J. van der Laan)
84ff1b2076ef91ce688930d0aa0a7f4078ef3e1d test: Add crc32c to subtree check linter (Wladimir J. van der Laan)
7cf13a513409c18d18dff2f6203b3630937b487d doc: Add crc32c subtree to developer notes (Wladimir J. van der Laan)
24d02a9ac00a82d172b171f73554a882df264c80 build: Update build system for new leveldb (Wladimir J. van der Laan)
2e1819311a59fb5cb26e3ca50a510bfe01358350 Squashed 'src/crc32c/' content from commit 224988680f7673cd7c769963d4035cb315aa3388 (Wladimir J. van der Laan)
66480821b36c839ab7615cb9309850015bceadb0 Squashed 'src/leveldb/' changes from f545dfabff4c2e9836efed094dba99a34fbc6b88..f8ae182c1e5176d12e816fb2217ae33a5472fdd7 (Wladimir J. van der Laan)
Pull request description:
This updates leveldb to currently newest upstream commit https://github.com/bitcoin-core/leveldb/commit/0c40829872a9f00f38e11dc370ff8adb3e19f25b:
- CRC32C hardware acceleration is now an external library [crc32c](https://github.com/google/crc32c). This adds acceleration on ARM, and should be faster on x86 because of using prefetch. It also makes it easy to support similar instruction sets on other platforms in the future.
- Thread handling uses C++11, instead of platform specific code.
- Native windows environment was added. No need to maintain our own hacky one, anymore.
- Upstream now builds using CMake. This doesn't mean we need to use that (phew), but internal configuration changed to a a series of checks, instead of OS profiles. This means the blanket error "Cannot build leveldb for $host. Please file a bug report' is removed.
All changes: https://github.com/google/leveldb/compare/a53934a3ae1244679f812d998a4f16f2c7f309a6...0c40829872a9f00f38e11dc370ff8adb3e19f25b
Pretty much all our changes have been subsumed by upstream, so we figured it was cleaner to start over with a new branch from upstream with the still-relevant patches applied: https://github.com/bitcoin-core/leveldb/tree/bitcoin-fork-new
There's quite some testing to be done (see below). See https://github.com/bitcoin-core/leveldb/issues/25 and https://github.com/bitcoin-core/leveldb/pull/26 for more history and context.
TODO:
- [x] Subtree `crc32c`
- [x] Make linters happy about crc32 subtree
- [x] Integrate `crc32c` library into build system
- [x] MSVC build system
ACKs for top commit:
sipa:
ACK 677fb8e92380d4deb6a3753047c01f7cf7b5af91
Tree-SHA512: 37ee92a750e053e924bc4626b12bb3fd81faa9f8c5ebaa343931fee810c45ba05aa6051fdea82535fa351bf2be7297801b98af9469865fc5ead771650a5d6240
|
|
|
|
|
|
98261b1e7b Merge #22: Clamp JSON object depth to PHP limit
54c4015415 Clamp JSON object depth to PHP limit
git-subtree-dir: src/univalue
git-subtree-split: 98261b1e7be4ce9820e25c8ce37d40cdef19ab20
|
|
19a354b11f85a3c6c81ff83bf702bf7a40cf5046 Output a descriptor in createmultisig and addmultisigaddress (Andrew Chow)
Pull request description:
Give a descriptor from `createmultisig` and `addmultisigaddress`.
Extracted from #16528 with `addmultisgaddress` and tests added.
ACKs for top commit:
Sjors:
tACK 19a354b11f85a3c6c81ff83bf702bf7a40cf5046
MarcoFalke:
ACK 19a354b11f85a3c6c81ff83bf702bf7a40cf5046
promag:
Code review ACK 19a354b11f85a3c6c81ff83bf702bf7a40cf5046.
meshcollider:
utACK 19a354b11f85a3c6c81ff83bf702bf7a40cf5046
Tree-SHA512: e813125fbbc358ea8d45b1748de16a29a94efd83175b748fb8fa3b0bfc8e783ed36b6c554d84f5d4ead1ba252a83a3e937b6c3f75da7b8d3b4e55f94d6013771
|
|
|
|
acf8abc7f3cf7efa418a46f9f69f23f1a5035582 gui: Fix unintialized WalletView::progressDialog (JoĆ£o Barbosa)
Pull request description:
#17911 shows that it's possible to read the unintialized `progressDialog` in https://github.com/bitcoin/bitcoin/blob/f32564f0a73c5ad1a107dd112e40516f39d1a51e/src/qt/walletview.cpp#L296-L297.
And the debugger shows
```
(gdb) bt
#0 0x0000555556687c60 in QProgressDialog::wasCanceled() const ()
#1 0x000055555572989f in WalletView::showProgress (this=0x5555577d7a70,
title=..., nProgress=1) at qt/walletview.cpp:322
```
Closes #17911.
ACKs for top commit:
hebasto:
ACK acf8abc7f3cf7efa418a46f9f69f23f1a5035582, I have reviewed the code and it looks OK, I agree it can be merged.
elichai:
utACK acf8abc7f3cf7efa418a46f9f69f23f1a5035582
kristapsk:
ACK acf8abc7f3cf7efa418a46f9f69f23f1a5035582
MarcoFalke:
ACK acf8abc7f3cf7efa418a46f9f69f23f1a5035582
Tree-SHA512: f5e6d873192d08d1a572e66e17c2e06d1ce27d01aa196b2a7ed591008641295bb02cda8ac90919ff2d2fc778316c2e143f8d36599e0d377779758853dfaf0a31
|
|
acd644b83d789a6cdfbeda19732119534d10058e build: remove --large-address-aware linker flag (fanquake)
Pull request description:
This flag was used when building 32-bit Windows executables, which we no-longer
do, and is not accepted by the linker for any of the hosts we currently build
for. i.e:
```bash
checking whether the linker accepts -Wl,--large-address-aware... no
```
--large-address-aware
If given, the appropriate bit in the "Characteristics" field of the COFF
header is set to indicate that this executable supports virtual addresses
greater than 2 gigabytes. This should be used in conjunction with the /3GB
or /USERVA=value megabytes switch in the "[operating systems]" section of
the BOOT .INI. Otherwise, this bit has no effect. [This option is specific
to PE targeted ports of the linker]
You can check that the appropriate bit in the COFF header of our 64-bit
Windows binaries is still be set using dumpbin. i.e:
```powershell
dumpbin /headers .\bitcoind.exe
FILE HEADER VALUES
<snip>
26 characteristics
Executable
Line numbers stripped
Application can handle large (>2GB) addresses
```
ACKs for top commit:
laanwj:
ACK acd644b83d789a6cdfbeda19732119534d10058e
Tree-SHA512: 9711e07bc08e843fcefd0517091a59cb7670dd107d03623a146d03fe73054d0e64f78489490b37f4708eab2c4800037f923b9ec92e7f53c3df9a590242f52b55
|
|
|
|
900d8f6f70859f528e84c5c38d0332f81d19df55 util: Disallow network-qualified command line options (Russell Yanofsky)
Pull request description:
Previously these were allowed but ignored.
This change implements one of the settings simplifications listed in #17508. Change includes release notes.
ACKs for top commit:
laanwj:
ACK 900d8f6f70859f528e84c5c38d0332f81d19df55
Tree-SHA512: ab020a16a86c1e8ec709fbf798d533879d32c565eceeb7eb785c33042c49c6b4d1108c5453d8166e4a2abffc2c8802fbb6d3b895e0ddeefa8f274fd647e3c8ad
|
|
fa5c6622c8ecf1954e7177888ad8c97a77b16fb7 doc: Use proper RPC help syntax in importmulti (MarcoFalke)
fab63111bec73859597e6ce0986f76e5e9959091 doc: Remove duplicate "comment" from listsinceblock RPC help (MarcoFalke)
fa04cd6cfc0330b62058ed169d621e08108dc87e doc: Properly document proxy_randomize_credentials as bool in getnetworkinfo (MarcoFalke)
fa9dec7c395897e8dbbb6de7a16ec5185a609d41 doc: Fix syntax error (trailing square bracket) in finalizepsbt (MarcoFalke)
faff5a60ed328d4c5fdef253e8935a351cb57bd0 doc: Fix syntax error (trailing square bracket) in walletprocesspsbt (MarcoFalke)
fa0545901daad32b09511cc61c4af1400c48088d doc: Add missing "optional" to "long" estimaterawfee RPC help (MarcoFalke)
Pull request description:
This fixes documentation of the following RPCs:
* estimaterawfee (hidden)
* https://bitcoincore.org/en/doc/0.19.0/rpc/wallet/walletprocesspsbt/
* https://bitcoincore.org/en/doc/0.19.0/rpc/rawtransactions/finalizepsbt/
* https://bitcoincore.org/en/doc/0.19.0/rpc/network/getnetworkinfo/
* https://bitcoincore.org/en/doc/0.19.0/rpc/wallet/listsinceblock/
* https://bitcoincore.org/en/doc/0.19.0/rpc/wallet/importmulti/
<!-- Also, it comes with a scripted diff to normalize whitespace and type names. (Previous attempts: #14601 and #14459)
ACKs for top commit:
laanwj:
ACK fa5c6622c8ecf1954e7177888ad8c97a77b16fb7
Tree-SHA512: 5a10956e12f8ce23e93a2ce8bafd6cae759d8a21658f79397e3bfce3e4aabd9658bdbd40acde49323dca958a9befee7166654994208c182dd60f483109621e17
|
|
e9434ee03efdfc0a5a54cf46561e95fd93cba007 Remove false positive GCC warning (Hennadii Stepanov)
Pull request description:
On master (f05c1ac444e0c893516535bfdf07c5c8cd9bce16) GCC compiler fires a false positive `-Wmaybe-uninitialized`:
```
wallet/wallet.cpp: In static member function āstatic std::shared_ptr<CWallet> CWallet::CreateWalletFromFile(interfaces::Chain&, const WalletLocation&, std::__cxx11::string&, std::vector<std::__cxx11::basic_string<char> >&, uint64_t)ā:
wallet/wallet.cpp:3913:27: warning: ā*((void*)& time_first_key +8)ā may be used uninitialized in this function [-Wmaybe-uninitialized]
Optional<int64_t> time_first_key;
^~~~~~~~~~~~~~
```
The same as #15292.
This PR leverages a workaround and removes the warning.
ACKs for top commit:
laanwj:
ACK e9434ee03efdfc0a5a54cf46561e95fd93cba007, removes the warning for me (gcc 7.4.0)
kristapsk:
ACK e9434ee03efdfc0a5a54cf46561e95fd93cba007
Tree-SHA512: 8820a8ba6a75aa6b1ac675a38c883a77f12968b010533b6383180aa66e7e0d570bf6300744903ead91cf9084e5345144959cd6b0cea1b763190b8dd49bacce75
|
|
7e2104433cd0905ccf94632511b3ca0ce5b0463b build: use macOS 10.14 SDK (fanquake)
ca5055a5aa07aba81a87cf12f6f0526a63c423b5 depends: native_cctools 921, ld64 409.12, libtapi 1000.10.8 (fanquake)
1de8c067c74cd171144c8a900a8a20efe3072c43 depends: clang 6.0.1 (fanquake)
Pull request description:
TLDR: This updates our macOS toolchain to use a newer version of Clang, cctools (including new [dependency on libtapi](https://github.com/tpoechtrager/cctools-port/tree/master#dependencies)), LD64 and the macOS SDK.
I've been testing depends builds (`HOST=x86_64-apple-darwin16`) inside a Debian Buster [Docker container](https://github.com/fanquake/core-review/blob/master/docker/debian.dockerfile), and running the resultant `bitcoind` and `bitcoin-qt` binaries on a macOS `10.14.4` system. The `.dmg` generated by a `make deploy` also mounts correctly on the same macOS system.
#### Clang
Upgraded from `3.7.1` to [`6.0.1`](https://releases.llvm.org/6.0.1/docs/ReleaseNotes.html)
#### cctools
* cctools `877.8` -> [`921`](https://opensource.apple.com/tarballs/cctools/)
* LD64 `253.9` -> [`409.12`](https://opensource.apple.com/source/ld64/)
* TAPI [`1000.10.8`](https://opensource.apple.com/tarballs/tapi/)
See [tpoechtrager/cctools-port](https://github.com/tpoechtrager/cctools-port/) and [tpoechtrager/apple-libtapi](https://github.com/tpoechtrager/apple-libtapi/).
#### macOS SDK
Upgraded from building against the macOS `10.11` SDK to the macOS `10.14` SDK.
#### TODO
- [x] Make the `10.14` SDK available to Travis.
Fixes: #16052
Closes: #14797
ACKs for top commit:
Sjors:
re-ACK 7e2104433cd0905ccf94632511b3ca0ce5b0463b (rebased from 248526e)
dongcarl:
ACK 7e21044
Tree-SHA512: fd36a33dbfb98c144240f8c69b77343e3f5bc18d8cf7d40fff61f51ad48925ec1872e6daba34c4045b18b4c2c84c22c744ebf4cba11061a0305eed13975ceefe
|
|
c0bc453135b3f549f800545075cb7bdb310c3ad4 build: remove deprecated key from macOS Info.plist (fanquake)
Pull request description:
Note that the current release binaries show correct version numbers everywhere in the GUI and macOS info dialogs (except for when you "space" click the app, shown in screenshots), and we haven't reintroduced the issue that #14701 fixed. This is just swapping a deprecated field for a newer one, as well as using the entire version string in two fields that we hadn't been previously.
Follows up discussion in #14701.
0.19.0.1
![0 19 0 1](https://user-images.githubusercontent.com/863730/70089170-a0576e80-15e5-11ea-975c-a6902a1ed95a.png)
This PR.
![master](https://user-images.githubusercontent.com/863730/70089178-a3525f00-15e5-11ea-9d63-7db67de014a5.png)
ACKs for top commit:
laanwj:
ACK c0bc453135b3f549f800545075cb7bdb310c3ad4
Tree-SHA512: 6191056d0cb6072b8a2170c8441ebfe500cf00cd41014bf5ee68fbf60b5bb5642e2fad9541f1c5abfaafdae6db3102c3add6169cefce3fc4a63d8b913ea35865
|
|
c86bc144081f960347232546f7d22deb65d27deb Make asmap Interpret tolerant of malicious map data (Pieter Wuille)
38c2395d7a905c87dc4630031849fd8e403e61bf Use ASNs for mapped IPv4 addresses correctly (Pieter Wuille)
6f8c93731203c111f86c39eaf2102f9a825d1706 Mark asmap const in statistics code (Pieter Wuille)
d58bcdc4b569a667b6974c3547b7ff6f665afce9 Avoid asmap copies in initialization (Pieter Wuille)
Pull request description:
Here are a few things to improve in the asmap implementation. The first two commits are just code improvements. The last one is a bugfix (the exsting code wouldn't correctly apply ASN lookups to mapped/embedded IPv4 addresses).
ACKs for top commit:
practicalswift:
ACK c86bc144081f960347232546f7d22deb65d27deb -- patch looks correct
naumenkogs:
utACK c86bc14
laanwj:
ACK c86bc144081f960347232546f7d22deb65d27deb
jonatack:
ACK c86bc144081f960347232546f7d22deb65d27deb code looks correct, built/ran tests, bitcoind with -asmap pointed to asmap/demo.map
Tree-SHA512: 1036f43152754d621bfbecfd3b7c7276e4670598fcaed42a3d275e51fa2cf3653e2c9e9cfa714f6c7719362541510e92171e076ac4169b55a0cc8908b2d514c0
|
|
eca56f89293b74f11ca631ff2a0793e970e65841 test: replace 'regtest' leftovers by self.chain (Sebastian Falbesoner)
Pull request description:
This is a follow-up PR to #16681 (fixes #18068), replacing all remaining hardcoded `"regtest"` strings in functional tests by `self.chain`.
Top commit has no ACKs.
Tree-SHA512: 96524649b33164938e5a95215991103ed7855ebab55ef788d4816b3fa5cbc03d8f3b0d39f2247a87522f289fd7f4daf25e059900b8462b5127eb154bbee89054
|
|
4d2aceaad8d28a54246b6639966e2278d2d795e3 tests: Add fuzzer asmap to FUZZERS_MISSING_CORPORA (temporarily) (practicalswift)
8d07706985a72b105b63efa289121d17d31607a1 tests: Add fuzzing harness for AS-mapping (asmap) (practicalswift)
Pull request description:
Add fuzzing harness for AS-mapping (`asmap`).
To test this PR:
```
$ make distclean
$ ./autogen.sh
$ CC=clang CXX=clang++ ./configure --enable-fuzz \
--with-sanitizers=address,fuzzer,undefined
$ make
$ src/test/fuzz/asmap
ā¦
```
ACKs for top commit:
MarcoFalke:
ACK 4d2aceaad8d28a54246b6639966e2278d2d795e3
jonatack:
ACK 4d2aceaad8d28a54246b6639966e2278d2d795e3
Tree-SHA512: bc4c63b48cd98c0cec9d10ecb43775b1bf1215241ff821fc7a866c7e2738605641fb88d044eabf2f48a8c16f2ced9ffce5165c9e6a83c73ece004350da7153e7
|
|
Commit 1abcecc40c518a98b7d17880657ec0247abdf125 replaced 'regtest' by self.chain
'regtest' "in almost all current tests", this commit takes care of the remaining
ones.
|
|
6c223152238d2e818e38357b03f38a4dbe9de016 build: add additional attributes to Win installer (fanquake)
Pull request description:
Fixes: #17170.
ACKs for top commit:
hebasto:
ACK 6c223152238d2e818e38357b03f38a4dbe9de016, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: d2ff2006b8df6a34b3a16270d3eb895b03cf6b3ca69404bc39adeb7d5e3b896ddab6ba831566dc966d8bdfba3f57ddf325762cddf3ad76d1427971d1bcc68255
|
|
some block files pruned
317fb96de9c6257972f1213b4ef2c3fe87dde99f Add search for first blk file with pruned node (Rjected)
Pull request description:
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always welcome.
* All other changes should have accompanying unit tests (see `src/test/`) or
functional tests (see `test/`). Contributors should note which tests cover
modified code. If no tests exist for a region of modified code, new tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or an
explanation of the potential issue as well as reasoning for the way the bug
was fixed.
* Features are welcome, but might be rejected due to design or scope issues.
If a feature is based on a lot of dependencies, contributors should first
consider building the system outside of Bitcoin Core, if possible.
* Refactoring changes are only accepted if they are required for a feature or
bug fix or otherwise improve developer experience significantly. For example,
most "code style" refactoring changes require a thorough explanation why they
are useful, what downsides they have and why they *significantly* improve
developer experience or avoid serious programming bugs. Note that code style
is often a subjective matter. Unless they are explicitly mentioned to be
preferred in the [developer notes](/doc/developer-notes.md), stylistic code
changes are usually rejected.
-->
When bitcoind is running in pruned mode, producing a hashlist with `./linearize-hashes.py linearize.cfg > hashlist.txt` and then executing `linearize-data.py linearize.cfg` will produce:
```
Read 313001 hashes
Input file /home/dan/.bitcoin/blocks/blk00000.dat
Premature end of block data
```
This happens because `linearize-data` starts by attempting to process `blk00000.dat` regardless of whether or not `blk00000.dat` actually exists - this may not be the case if working with a pruned node.
This PR adds a function which finds the first block file that does exist, and calls that function when the `BlockDataCopier` is initialized.
This is a refactor of #16431.
<!--
Bitcoin Core has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial time
effort to review. There is a huge lack of active reviewers on the project, so
patches often sit for a long time.
-->
ACKs for top commit:
darosior:
ACK 317fb96de9c6257972f1213b4ef2c3fe87dde99f
laanwj:
Code review ACK 317fb96de9c6257972f1213b4ef2c3fe87dde99f
theStack:
Code review ACK https://github.com/bitcoin/bitcoin/pull/17336/commits/317fb96de9c6257972f1213b4ef2c3fe87dde99f
Tree-SHA512: fc8014282df6cfe7b267e64db8ce7d82b86b758c302fbfea4a3c39b62d93512f5c2e31a0de4e9c5ec18fc0268c917f011257d37b45afaef6033eec90e4aa585f
|
|
1abcecc40c518a98b7d17880657ec0247abdf125 Tests: Use self.chain instead of 'regtest' in almost all current tests (Jorge TimĆ³n)
Pull request description:
Simply avoiding the hardcoded string in more places for consistency.
It can also allow for more easily reusing tests for other chains other than regtest.
Separated from #8994 .
Continues #16509 .
It is still not complete (ie to be complete, we need the -chain parameter in #16680 and make whether acceptnonstdtxs is allowed for that chain or not customizable for regtest [or for custom chains like in #8994 ] ). But while being incomplete like #16509 , it's quite simple to review and another step forward IMO.
ACKs for top commit:
Sjors:
re-ACK 1abcecc. I think it's an improvement even if incomplete and if some PR's might accidentally bring "regtest" back. Subsequent improvements hopefully don't have to touch 16 files.
elichai:
Code review ACK 1abcecc40c518a98b7d17880657ec0247abdf125
ryanofsky:
Code review ACK 1abcecc40c518a98b7d17880657ec0247abdf125.
ryanofsky:
Code review ACK 1abcecc40c518a98b7d17880657ec0247abdf125
Tree-SHA512: 5620de6dab235ca8bd8670d6366c7b9f04f0e3ca9c5e7f87765b38e16ed80c17d7d1630c0d5fd7c5526f070830d94dc74cc2096d8ede87dc7180ed20569509ee
|
|
ff59bcd3213ef61f2167c0aa60fcaf5afbc20c61 gui: Drop PeerTableModel dependency to ClientModel (JoĆ£o Barbosa)
Pull request description:
Class `PeerTableModel` doesn't actually depend on `ClientModel`.
ACKs for top commit:
Empact:
Code Review ACK https://github.com/bitcoin/bitcoin/pull/18060/commits/ff59bcd3213ef61f2167c0aa60fcaf5afbc20c61
hebasto:
ACK ff59bcd3213ef61f2167c0aa60fcaf5afbc20c61, tested on Linux Mint 19.3. No changes in behavior are observed.
Tree-SHA512: 29fa3c316c05b8f7b9340e5859bbb8c3a0b826aa7c865c892cfa13b5ad30f822fcaae4e01555f7860cd1727f20b7ef555a808235522a04a6eebaaa7b605f8595
|
|
|
|
|
|
|
|
Co-Authored-By: Carl Dong <accounts@carldong.me>
|
|
This also removes the obsolete mlinker-version option
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
This also removes some now-unnecessary cctools hacks.
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
0a50019fde7781263e0c8f041d1d9dcb0dee77e8 Walk pindexBestHeader back to ChainActive().Tip() if it is invalid (Matt Corallo)
Pull request description:
Instead of keeping pindexBestHeader set to the best header we've
ever seen, reset it back to our validated tip if we find an ancestor
of it turns out to be invalid. While the name is now a bit confusing,
this matches much better with how it is used in practice, see below.
Further, this opens up more use-cases for it in the future, namely
aggressively searching for new peers in case we have discovered
(possibly via some covert channel) headers which we do not know to be
invalid, but which we cannot find block data for.
Places pindexBestHeader is used:
* Various GUI displays of the best header and getblockchaininfo["headers"],
I don't think changing this is bad, and if anything this is less confusing
in the presence of an invalid block.
* IsCurrentForFeeEstimation(): If anything I think ensuring pindexBestHeader
isn't some crazy invalid chain is better than the alternative, even in the
case where you are rejecting the current chain due to hardware error (since
hopefully in that case you won't get any new blocks anyway).
* ConnectBlock assumevalid checks: We use pindexBestHeader to check that the
block we're connecting leads to something with nMinimumChainWork (preventing
a user-set assumevalid from having bogus work) and that the block we're
connecting leads to pindexBestHeader (I'm not too worried about this one -
it's nice to "disable" assumevalid if we have a long invalid headers chain,
but I don't see it as a critical protection).
* BlockRequestAllowed() uses pindexBestHeader as its target to ensure the
requested block is within a month of the "current chain". I don't think this
is a meaningful difference, if we're rejecting the current tip we're
trivially fingerprintable anyway, and if the chain really does have a bunch
of invalid crap near the tip, using the best not-invalid header is likely a
better criteria.
* ProcessGetBlockData uses pindexBestHeader as the "current chain" definition
of whether a block request is "historical" for the purpose of bandwidth
limiting. Similarly, I don't see why this is a meaningful change.
* We use pindexBestHeader for requesting missing headers on receipt of a
headers/compact block message or block inv as well as for initial getheaders.
I think this is definitely wrong, using the best not-invalid header for such
requests is much better.
* We use pindexBestHeader to define the "current chain" for deciding when
we're close to done with initial headers sync. I don't think this is a
meaningful change.
* We use pindexBestHeader to decide if initial headers sync has timed out. If
we're rejecting the chain due to hardware error this may result in
additional cases where we ban a peer, but this is already true, so I think
its fine.
ACKs for top commit:
fjahr:
ACK 0a50019fde7781263e0c8f041d1d9dcb0dee77e8
kallewoof:
ACK 0a50019fde7781263e0c8f041d1d9dcb0dee77e8
ariard:
utACK 0a50019
Tree-SHA512: 2ecfa973a9878a00313ae7ede94a9bd7710e0caf55b544b10bbc46dc463a0478cbaf477e6cdd072356d5a0c5fb3848e9339284af785a2995c20bae8bd23f23e5
|
|
bd5a02692853f7240a4fdc593d7d0123d7916e45 Make UpdateTransactionsFromBlock use Epochs (Jeremy Rubin)
2ccb7cca4ac67198ac89bd58f5b4ae41a5163ceb Add Epoch Guards to CTXMemPoolEntry and CTxMemPool (Jeremy Rubin)
Pull request description:
UpdateTransactionsFromBlock is called during a re-org. When a re-org occurs, all of the transactions in the mempool may be descendants from a transaction which is in the pre-reorg block. This can cause us to propagate updates, worst case, to every transaction in the mempool.
Because we construct a `setEntries setChildren`, which is backed by a `std::set`, it is possible that this algorithm is `O(N log N)`.
By using an Epoch visitor pattern, we can limit this to `O(N)` worst case behavior.
Epochs are also less resource intensive than almost any set option (e.g., hash set) because they are allocation free.
This PR is related to https://github.com/bitcoin/bitcoin/pull/17268, it is a small subset of the changes which have been refactored slightly to ease review. If this PR gets review & merge, I will follow up with more PRs (similar to #17268) to improve the mempool
ACKs for top commit:
sdaftuar:
ACK bd5a02692853f7240a4fdc593d7d0123d7916e45
adamjonas:
Just to summarize for those looking to review - as of bd5a026 there are 3 ACKs (@sdaftuar, @ariard, and @hebasto) and one "looks good" from @ajtowns with no NACKs or any show-stopping concerns raised.
ajtowns:
ACK bd5a02692853f7240a4fdc593d7d0123d7916e45 (code review)
ariard:
Code review ACK bd5a026
hebasto:
ACK bd5a02692853f7240a4fdc593d7d0123d7916e45, modulo some nits and a typo.
Tree-SHA512: f0d2291085019ffb4e1119edeb9f4a89c1a572d1cb5b4bdf5743dd0152e721e1935f5155dcae84e1e5bda5ffdf6224c488c1e200bd33bedca9f5ca22d5f5139f
|
|
9a299a59cc8a9ab516e047356c5bc0e93774b557 net: reference instead of copy in BlockConnected range loop (Jon Atack)
Pull request description:
Reference elements in range for loop instead of copying them and
fix Clang `-Wrange-loop-analysis` warning introduced in a029e18
```
net_processing.cpp:1185:25: warning: loop variable 'ptx' of
type 'const std::shared_ptr<const CTransaction>' creates a copy from
type 'const std::shared_ptr<const CTransaction>' [-Wrange-loop-analysis]
for (const auto ptx : pblock->vtx) {
^
net_processing.cpp:1185:14: note: use reference type
'const std::shared_ptr<const CTransaction> &' to prevent copying
for (const auto ptx : pblock->vtx) {
^~~~~~~~~~~~~~~~
1 warning generated.
```
ACKs for top commit:
Empact:
ACK https://github.com/bitcoin/bitcoin/pull/18054/commits/9a299a59cc8a9ab516e047356c5bc0e93774b557
MarcoFalke:
ACK 9a299a59cc8a9ab516e047356c5bc0e93774b557
promag:
ACK 9a299a59cc8a9ab516e047356c5bc0e93774b557.
elichai:
ACK 9a299a59cc8a9ab516e047356c5bc0e93774b557
emilengler:
ACK 9a299a5.
Tree-SHA512: 9284d1b00684877505454a05071212758c8cea083534e2eec09bfc8a9c3059eea811d2008f6a5a678539444f0d5b3134db1bd23da6514b3d3a1440634c8b53be
|
|
to fix -Wrange-loop-analysis warning introduced in a029e18
|
|
d3bc18408146e91b3836f72360ff6fa2420b6887 doc: update release notes with getaddressinfo label deprecation (Jon Atack)
72af93f36479dc12d795f1d05fa3d8fbd9b293bd test: getaddressinfo label deprecation test (Jon Atack)
d48875fa20d0b71b978cb3d1f85dd9ec14e664cc rpc: deprecate getaddressinfo label field (Jon Atack)
dc0cabeda49a7edbfa71df22846721b6f6224aea test: remove getaddressinfo label tests (Jon Atack)
c7654af6f830577a54df12b5d65df93532db0dc2 doc: address pr17578 review feedback (Jon Atack)
Pull request description:
This PR builds on #17578 (now merged) and deprecates the rpc getaddressinfo `label` field. The deprecated behavior can be re-enabled by starting bitcoind with `-deprecatedrpc=label`.
See http://www.erisian.com.au/bitcoin-core-dev/log-2019-11-22.html#l-622 and https://github.com/bitcoin/bitcoin/pull/17283#issuecomment-554458001 for more context.
Reviewers: This PR may be tested manually by building, then running bitcoind with and without the `-deprecatedrpc=label` flag while verifying the rpc getaddressinfo output and help text.
Next step: add support for multiple labels.
ACKs for top commit:
jnewbery:
ACK d3bc18408146e91b3836f72360ff6fa2420b6887
laanwj:
ACK d3bc18408146e91b3836f72360ff6fa2420b6887
meshcollider:
utACK d3bc18408146e91b3836f72360ff6fa2420b6887
Tree-SHA512: f954402884ec54977def332c8160fd892f289b0d2aee1e91fed9ac3220f7e5b1f7fc6421b84cc7a5c824a0582eca4e6fc194e4e33ddd378c733c8941ac45f56d
|
|
|
|
cb8a86d9f952401eaad68b2e3818ce50f7befd91 gui: Remove WalletView and BitcoinGUI circular dependency (JoĆ£o Barbosa)
ac3d10777d65b68862c6deb57594c8fc4d21ca77 gui: Add transactionClicked and coinsSent signals to WalletView (JoĆ£o Barbosa)
Pull request description:
Essentially moves the code in `WalletView::setBitcoinGUI` to the only caller. Two new signals are added beforehand in the first commit so that the connections in `WalletFrame` are all from the wallet view.
ACKs for top commit:
hebasto:
ACK cb8a86d9f952401eaad68b2e3818ce50f7befd91, tested on Linux Mint 19.3.
jonasschnelli:
utACK cb8a86d9f952401eaad68b2e3818ce50f7befd91
Tree-SHA512: 250316cd3689e51c8cded9ccd75963c836dcafa6db25d684f2aa691dea9738895f9140793e0f925784909e39f8257f7e1c7d611e8bd6d6634e1a50333f4ddb1e
|
|
3aee10b80b9d9a0f5172fc2ee75f03a37d5c3863 gui: Drop ShutdownWindow dependency to BitcoinGUI (JoĆ£o Barbosa)
61eb058cc10592cfa314ba2209fb370706100e8b gui: Drop BanTableModel dependency to ClientModel (JoĆ£o Barbosa)
Pull request description:
`ShutdownWindow::showShutdownWindow` just needs a widget to center the shutdown window and to borrow its title.
ACKs for top commit:
hebasto:
ACK 3aee10b80b9d9a0f5172fc2ee75f03a37d5c3863, since previous review only suggested change `QWidget` --> `QMainWindow`
jonasschnelli:
utACK 3aee10b80b9d9a0f5172fc2ee75f03a37d5c3863
Tree-SHA512: e15cb6ee274730bd071d3d97b540c5059e5c655248d69a37c3fd00f2aacc6cfcb36b9a65755718027e15482ec8e5e85534c1dc13d0ddb4e0680df03fbf6571f2
|
|
|
|
|
|
|
|
|
|
check
a029e18c2bf67dd00552b0f4bbc85fa2fa5b973b Use rolling bloom filter of recent block tx's for AlreadyHave() check (Suhas Daftuar)
Pull request description:
In order to determine whether to download or process a relayed transaction, we first try to check whether we already have the transaction -- either in the mempool, in our filter of recently rejected transactions, in our orphan pool, or already confirmed in a block.
Prior to this commit, the heuristic for checking whether a transaction was confirmed in a block is based on whether there's a coin cache entry corresponding to the 0- or 1-index vout of the tx. While that is a quick check, it is very imprecise (eg if those outputs were already spent in another block, we wouldn't detect that the transaction has already been confirmed) -- we can do better by just keeping a rolling bloom filter of the transactions in recent blocks, which will better capture the case of a transaction which has been confirmed and then fully spent.
This should reduce the bandwidth that we waste by requesting transactions which will not be accepted to the mempool.
To avoid relay problems for transactions which have been included in a recent block but then reorged out of the chain, we clear the bloom filter whenever a block is disconnected.
ACKs for top commit:
MarcoFalke:
re-ACK a029e18c2b only stylistic and comment fixups š“
sipa:
utACK a029e18c2bf67dd00552b0f4bbc85fa2fa5b973b
jonatack:
Code review ACK a029e18c2bf67dd00552b0f4bbc85fa2fa5b973b also built/ran tests and am running bitcoind with mempool debug logging and custom logging. Looked a bit into CRollingBloomFilter and also the mempool median time past checks mentioned above; I don't have a deep understanding of those areas yet but the concept here and changes LGTM. Tests and other optimisations could be added as a follow-up. In favor of seeing this move forward if no major immediate concerns.
Tree-SHA512: 784c9a35bcd3af5db469063ac7d26b4bac430e451e5637a34d8a538c3ffd1433abdd3f06e5584e7a84bfa9e791449e61819397b5a6c7890fa59d78ec3ba507b2
|
|
|