6200fbf54f build: rename --enable-ebpf to --enable-usdt (0xb10c)
e158a2a7aa build: add systemtap's sys/sdt.h as depends (0xb10c)
Pull request description:
There has been light conceptual agreement on including the Userspace, Statically Defined Tracing tracepoints in Bitcoin Core release builds. This, for example, enables user to hook into production deployments, if they need to. Binaries don't have to be switched out. This is possible because we don't do [expensive computations](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#no-expensive-computations-for-tracepoints) only needed for the tracepoints. The tracepoints are NOPs when not used.
Systemtap's `sys/sdt.h` header is required to build Bitcoin Core with USDT support. The header file defines the `DTRACE_PROBE` macros used in [`src/util/trace.h`](https://github.com/bitcoin/bitcoin/blob/master/src/util/trace.h). This PR adds Systemtap 4.5 (May 2021) as dependency. GUIX builds for Linux hosts now include the tracepoints.
Closes https://github.com/bitcoin/bitcoin/issues/23297.
ACKs for top commit:
fanquake:
ACK 6200fbf54f - tested enabling / disabling and with/without SDT from depends. We can follow up with #23819, #23907 and #23296, and if any serious issues arise before feature freeze, it is easy for us to flip depends such that USDT becomes opt-in, rather than opt-out, and thus, releases would be tracepoint free.
Tree-SHA512: 0263f44892bf8450e8a593e4de7a498243687f8d81269e1c3283fa8354922c7cf93fddef4b92cf5192d33798424aa5812e03e68ef8de31af078a32dd34021382
2fda0c7851 doc: Drop no longer required notes for Windows builds (Hennadii Stepanov)
f09ed92be1 build: Try posix-specific CXX first for mingw32 host (Hennadii Stepanov)
Pull request description:
On master (1186910b6b), when cross-compiling for Windows using our depends build system, we must manually choose the POSIX thread model for the `x86_64-w64-mingw32-g++` compiler.
This PR improves the build system to make this choice automa**g**ically.
ACKs for top commit:
jarolrod:
re-ACK 2fda0c7851
shaavan:
tACK 2fda0c7851
Tree-SHA512: ad3bbdfe84b3c8eb56e102aa0abdc76fd864b2724ac59c9a12a798c57d1c5a1172682172588019d5d1715801a9f201fd9424effbd858e8dc30607c23c0d5941f
e09773d20a build: use a static .tiff for macOS .dmg over generating (fanquake)
Pull request description:
For demonstration, after [discussion in #23778](https://github.com/bitcoin/bitcoin/pull/23778#issuecomment-1003005503), and the question as to why we can't just have a `background.tiff` that we copy into the macOS DMG, and do away with the somewhat convoluted image generation steps.
From my understanding, the only reason we have this image generation as part of our build system is so that forks of Core can adapt the imagery for their own branding via `PACKAGE_NAME`. It don't think it provides much value to us, and could just have a static .tiff that we copy into the dmg (replacing the .svg that currently lives in macdeploy/).
Doing this would eliminate the following build dependencies:
For native macOS:
* `sed` (usage in Makefile.am)
* `librsvg` (rsvg-convert)
* `tiffutil`
Linux macOS cross-compile:
* `sed` (usage in Makefille.am)
* `librsvg`
* `tiffcp`
* `convert` (imagemagick)
* `font-tuffy`
Guix Build:
```bash
bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
c98d67796863f4b1bab0ad600d46bd74e744d94072cbd4bc856a6aeaba3bb329 guix-build-e09773d20a92/output/dist-archive/bitcoin-e09773d20a92.tar.gz
3336f90bab312798cb7665e2b4ae24d1a270fb240647d5fed8dbfcd83e3ed37e guix-build-e09773d20a92/output/x86_64-apple-darwin/SHA256SUMS.part
8fd680c7ee158c64bad212385df7b0b302c6c2143d4e672b4b0eb5da41f9256d guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.dmg
34f54177c2f0700e8cfaf5d85d91e404807cd9d411e22006cdff82653e5f4af2 guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.tar.gz
da6b8f54ef755d40330c8eac4f5bd0329637e827be9ee61318600d5d0bdcc3dc guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx64.tar.gz
```
ACKs for top commit:
hebasto:
ACK e09773d20a
jarolrod:
ACK e09773d20a
Zero-1729:
ACK e09773d20a
Tree-SHA512: 0ad06699a5451daa8cfaaa46759eb7bd85254a72e23f857f70d433a2ffb1a4bf6dd464d9c4ac9f8c20aab045f4e2b61c6dcdcbcceef96ce515b1a0c501665b1f
62c173ae4c doc: remove CC_FOR_BUILD from OpenBSD build doc (fanquake)
Pull request description:
This is no-longer necessary after upstream libsecp256k1 changes that have been pulled into our repo.
ACKs for top commit:
theStack:
ACK 62c173ae4c
Tree-SHA512: 7c328185afec366ff49096512b2fcc3c2f2a2381875f65f5444ffacf118f9a51e4e2237daaae6b32f742a7c4c54c1fbba7cee4e1807d7c4816123f6b0e7c33c8
059f88b6a9 Add RPC help for getblock verbosity level 3 (Kiminuo)
1bdd5f6322 Address review comments from #22918 (Kiminuo)
Pull request description:
This is a follow-up PR to #22918 which addresses review comments (first commit). The second commit adds missing RPC help for verbosity level 3.
ACKs for top commit:
pg156:
ACK 059f88b6a9
laanwj:
re-ACK 059f88b6a9
Tree-SHA512: f27d53ac34b93a304ef5668701ed2b5c986a926bc8ad0df4de89695fc9e1df26acb008611451319ea897658acd9c56c6a0555d60359960c9cd28238ebefa2d50
The sys/sdt.h header is required to build Bitcoin Core with Userspace
Statically Defined Tracing support. Systemtap version 4.5 (May 2021)
is used as the most recent version 4.6 (Nov 2021) fails to build.
See e.g. https://sourceware.org/git/?p=systemtap.git;a=commit;h=1d3653936fc1fd13135a723a27e6c7e959793ad0
As Systemtap itself is not needed, the build steps (configure and
make) are skipped. We require fewer build dependecies and don't
waste time building depends we don't end up using. However, the
configure step would normally processes sys/sdt-config.h.in. The
resulting sdt-config.h defines _SDT_ASM_SECTION_AUTOGROUP_SUPPORT
(either 0 or 1 to indicate whether the assembler supports "?" in
.pushsection directives). For now, we assume all currently used
assemblers supports this feature and remove the check from the
sys/sdt.h header file in a patch.
Co-authored-by: Michael Ford <fanquake@gmail.com>
82858bab64 [doc] CPFP carve out and single-conflict RBF exemption (glozow)
1fd49eb498 [doc] clarify RBF difference from BIP125 (glozow)
919ae8b8cd [doc] current rbf policy (glozow)
Pull request description:
Since RBF was first implemented and BIP125 was written, our code has changed, people have highlighted implementation differences, and some people have proposed further changes to it. Many people seem to support the idea of documenting our _current_ RBF policy as it stands today.
As the ancestor/descendant limit carve-out exemptions are very related to RBF, it seemed appropriate to group them with this PR.
Related to #22806 - it seems that these policies are the most confusing for people, or at least the most documentation-requested.
ACKs for top commit:
dunxen:
ACK 82858ba
t-bast:
ACK 82858bab64, thanks @glozow!
darosior:
re-ACK 82858bab64
ariard:
ACK 82858ba
Tree-SHA512: 5d296537cce3488c18179c0aa76c739ca02fdc424e5aa17129b4cdd0d057358f86bcc1e92a9857bd2c60495f834fe9d9406d1a9f8ac5cfc8f0f4f4c27ec4f8e1
2b64fa3251 Update REST docs with new accessors (Matt Corallo)
ef7c8228fd Expose block filters over REST. (Matt Corallo)
Pull request description:
This adds a new rest endpoint:
/rest/blockfilter/filtertype/requesttype/blockhash (eg
/rest/blockfilter/basic/header/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.hex)
which exposes either the filter "header" or the filter data itself.
Most of the code is cribbed from the equivalent RPC.
You can test it at 000000005bed57667a35d23f2334c4f86d.hex
ACKs for top commit:
dergoegge:
ACK 2b64fa3251 - Adding blockfilters to the REST interface is analogous to serving other public data such as transactions or blocks.
Tree-SHA512: d487bc694266375c94d6fcf2e9d788a8a42a3b94e8d3290e46335a64cbcde55084ce5ea6119b79a4065888d94d7c3ae25a59a901fa46e3711f0eb296add12696
It can be argued that BIP125#1 signaling is honored because
descendants of signaling transactions are replaceable by RBF.
Regardless, since there are multiple details in our RBF policy that are
not captured in BIP125, point to our doc instead.
9544ab60ce doc: Improve ZMQ documentation (node01)
Pull request description:
This PR intends to clarify:
. when ZMQ notifications occur
. the message structure of each topic
Closes https://github.com/bitcoin/bitcoin/issues/23452#issue-1046579585
ACKs for top commit:
theStack:
ACK 9544ab60ce
Tree-SHA512: 3b1314ad5eb8c359ffabd91ce9b47cf6cf8efa69be083a3bb5d865833ac67d7a88a8e012c4a4f59f2cd2a0e7f491e828897e85e9d01bae72ee83c4a6ad459f6e
1ef2c03452 Add multisig tutorial (lsilva01)
Pull request description:
This PR adds a mutisig tutorial, as requested in https://github.com/bitcoin/bitcoin/issues/21278
Although there is already a brief explanation and a functional test about the multisig implemented in https://github.com/bitcoin/bitcoin/pull/22067, this tutorial proposes to use the signet (instead of regtest), bringing the reader closer to a real environment and explaining some functions in more detail.
I'm not sure if this format should be in this repository or on some wiki page. But as there is an open issue regarding this matter, that is my suggestion.
ACKs for top commit:
Sjors:
re-utACK 1ef2c03452
prayank23:
ACK 1ef2c03452
Tree-SHA512: 2c3f17a8c50e554f802029dceb28ab90a77021f135b8cbd77dca3879ba1f1a0eac6bda0afb90d1ff6b8116fb0628471687d3fb77bb255ef5d8b9590b775cbce9
d5cab1a96d Add createmultisig and addmultisigaddress warnings release note (Samuel Dobson)
e46fc935aa Add warnings field to addmultisigaddress to warn about uncompressed keys (Samuel Dobson)
d1a9742623 Add warnings field to createmultisig to warn about uncompressed keys (Samuel Dobson)
Pull request description:
Fixes#21368
Currently, if there are any uncompressed keys when calling `AddAndGetMultisigDestination`, it will just default to a legacy address regardless of the chosen `address_type`. Rather than keeping this silent behaviour which may be confusing to users, we explicitly add a `warnings` field which will warn the user why their address format is different.
ACKs for top commit:
achow101:
ACK d5cab1a96d
Tree-SHA512: c2ac7f7689251bd4fcd8c26506f053921fbaf34c7a26a74e82ebc7f82cc0bd25407fd7954bf98365dcafa51fa45dcdbee6214320580ca69509690c3555e71cc0
6575d354c8 build: Bump Fonconfig version up to 2.12.6 (Hennadii Stepanov)
Pull request description:
This PR gets rid of `remove_char_width_usage.patch`.
Some additional observations:
1. Newer Fontconfig versions (2.13.0 and 2.13.1) introduce a new dependency, `uuid`, in the [`7b48fd3dd406b926f0e5240b211f72197ed538a9`](7b48fd3dd4) commit
2. In Fonconfig 2.13.1 (the current stable) excludes the `fcobjshash.h` from the distributive archive (see [`31269e3589e0e6432d12f55db316f4c720a090b5`](31269e3589)), that makes our `gperf_header_regen.patch` unusable, and requires `gperf` as a dependency.
ACKs for top commit:
fanquake:
ACK 6575d354c8 - from the best I can determine this doesn't have any versioning / ABI implications. The ABI difference between 2.12.1 and 2.12.6 is two symbol additions, neither of which are used by Qt. Fontconfig seems to be better at maintaining backwards compatibility compared to a library like Freetype.
Tree-SHA512: 36780a0c5a658469697e524d682ebab56c320cb04f8297bc215f4552f183d4f560501fb0a869982fd9053d4a2d571c7fd971d8f5e96c9da9a9d142c485e3baa4
1dcba996d3 Coinbase receivedby rpcs release notes (Andrew Toth)
b5696750a9 Test including coinbase transactions in receivedby wallet rpcs (Andrew Toth)
bce20c34d6 Include coinbase transactions in receivedby wallet rpcs (Andrew Toth)
Pull request description:
The current `*receivedby*` RPCs filter out coinbase transactions. This doesn't seem correct since an output to your address in a coinbase transaction *is* receiving those coins.
This PR corrects this behaviour. Also, a new option `include_immature_coinbase` is added (default=`false`) that includes immature coinbase transactions when set to true.
However, since this is potentially a breaking change this PR introduces a hidden configuration option `-deprecatedrpc=exclude_coinbase`. This can be set to revert to previous behaviour. If no reports of broken workflow are received, then this option can be removed in a future release.
Fixes https://github.com/bitcoin/bitcoin/issues/14654.
ACKs for top commit:
jnewbery:
reACK 1dcba996d3
Tree-SHA512: bfc43b81279fea5b6770a4620b196f6bc7c818d221b228623e9f535ec75a2406bc440e3df911608a3680f11ab64c5a4103917162114f5ff7c4ca8ab07bb9d3df
2f9515f37a rpc: move fees object to match help (josibake)
07ade7db8f doc: add release note for fee field deprecation (josibake)
2ee406ce3e test: add functional test for deprecatedrpc=fees (josibake)
35d928c632 rpc: deprecate fee fields from mempool entries (josibake)
Pull request description:
per #22682 , top level fee fields for mempool entries have been deprecated since 0.17 but are still returned. this PR properly deprecates them so that they are no longer returned unless `-deprecatedrpc=fees` is passed.
the first commit takes care of deprecation and also updates `test/functional/mempool_packages.py` to only use the `fees` object. the second commit adds a new functional test for `-deprecatedrpc=fees`
closes#22682
## questions for the reviewer
* `-deprecatedrpc=fees` made the most sense to me, but happy to change if there is a name that makes more sense
* #22682 seems to indicate that after some period of time, the fields will be removed all together. if we have a rough idea of when this will be, i can add a `TODO: fully remove in vXX` comment to `entryToJSON`
## testing
to get started on testing, compile, run the tests, and start your node with the deprecated rpcs flag:
```bash
./src/bitcoind -daemon -deprecatedrpc=fees
```
you should see entries with the deprecated fields like so:
```json
{
"<txid>": {
"fees": {
"base": 0.00000671,
"modified": 0.00000671,
"ancestor": 0.00000671,
"descendant": 0.00000671
},
"fee": 0.00000671,
"modifiedfee": 0.00000671,
"descendantfees": 671,
"ancestorfees": 671,
"vsize": 144,
"weight": 573,
...
},
```
you can also check `getmempoolentry` using any of the txid's from the output above.
next start the node without the deprecated flag, repeat the commands from above and verify that the deprecated fields are no longer present at the top level, but present in the "fees" object
ACKs for top commit:
jnewbery:
reACK 2f9515f37a
glozow:
utACK 2f9515f37a
Tree-SHA512: b175f4d39d26d96dc5bae26717d3ccfa5842d98ab402065880bfdcf4921b14ca692a8919fe4e9969acbb5c4d6e6d07dd6462a7e0a0a7342556279b381e1a004e
78a6bc6919 build, qt: Use Android NDK r23 LTS (Hennadii Stepanov)
Pull request description:
This is a continuation of bitcoin/bitcoin#23478, and, thanks to bitcoin/bitcoin#23489, a oneline patch is only required to be able build the `qt` package in depends with Android NDK r23 LTS.
ACKs for top commit:
fanquake:
ACK 78a6bc6919
Tree-SHA512: 09c6e8739ecbcbf5fdd6c2103577be2676eb448941f97c781f476918056c8405d2531d5cef8f240e4d1205c2d49f879edbba74dd5e77799a887b76a5c76ebe5b
a4fe70171b Make Bech32 LocateErrors return error list rather than using out-arg (Samuel Dobson)
2fa4fd1961 Use std::iota instead of manually pushing range (Samuel Dobson)
405c96fc9f Use bounds-checked array lookups in Bech32 error detection code (Samuel Dobson)
28d9c2857f Simplify encoding of e in GF(1024) tables to (1,0) (Samuel Dobson)
14358a029d Replace GF1024 tables and syndrome constants with compile-time generated constexprs. (Samuel Dobson)
63f7b69779 Update release note for bech32 error detection (Samuel Dobson)
c8b9a224e7 Report encoding type in bech32 error message (Samuel Dobson)
92f0cafdca Improve Bech32 boost tests (Samuel Dobson)
bb4d3e9b97 Address review comments for Bech32 error validation (Samuel Dobson)
Pull request description:
A number of follow-ups and improvements to the bech32 error location code, introduced in #16807.
Notably, this removes the hardcoded GF1024 tables in favour of constexpr table generation.
ACKs for top commit:
laanwj:
Re-ACK a4fe70171b
Tree-SHA512: 6312373c20ebd6636f5797304876fa0d70fa777de2f6c507245f51a652b3d1224ebc55b236c9e11e6956c1e88e65faadab51d53587078efccb451455aa2e2276
21b58f430f util: ParseByteUnits - Parse a string with suffix unit [k|K|m|M|g|G|t|T] (Douglas Chimento)
Pull request description:
A convenience utility for parsing human readable strings sizes e.g. `500G` is `500 * 1 << 30`
The argument/setting `maxuploadtarget` now accept human readable byte units `[k|K|m|M|g|G||t|T]`
This change backward compatible, defaults to `M` if no unit specified.
ACKs for top commit:
vasild:
ACK 21b58f430f
ryanofsky:
Code review ACK 21b58f430f. Only changes since last review are dropping optional has_value call, fixing comment punctuation, squashing commits.
Tree-SHA512: c9b85acc0f77c847a0290b27ac5dc586ecc078110cf133063140576a04c11aa9c553159b9b4993488edcf6e60db6837de7c83b2964639bc21e8ffa4d455a5eb7
88cc481092 Modify copyright header on Bech32 code (Samuel Dobson)
5599813b80 Add lots of comments to Bech32 (Samuel Dobson)
2eb5792ec7 Add release notes for validateaddress Bech32 error detection (MeshCollider)
42d6a029e5 Refactor and add more tests for validateaddress (Samuel Dobson)
c4979f77c1 Add boost tests for bech32 error detection (MeshCollider)
02a7bdee42 Add error_locations to validateaddress RPC (Samuel Dobson)
b62b67e06c Add Bech32 error location function (Samuel Dobson)
0b06e720c0 More detailed error checking for base58 addresses (Samuel Dobson)
Pull request description:
Addresses (partially) #16779 - no GUI change in this PR
Adds a LocateError function the bech32 library, which is then called by `validateaddress` RPC, (and then eventually from a GUI tool too, future work). I think modifying validateaddress is nicer than adding a separate RPC for this.
Includes tests.
Based on https://github.com/sipa/bech32/blob/master/ecc/javascript/bech32_ecc.js
Credit to sipa for that code
ACKs for top commit:
laanwj:
Code review and manually tested ACK 88cc481092
ryanofsky:
Code review ACK 88cc481092 with caveat that I only checked the new `LocateErrors` code to try to verify it didn't have unsafe or unexpected operations or loop forever or crash. Did not try to verify behavior corresponds to the spec. In the worst case bugs here should just affect error messages not actual decoding of addresses so this seemed ok.
w0xlt:
tACK 88cc481
Tree-SHA512: 9c7fe9745bc7527f80a30bd4c1e3034e16b96a02cc7f6c268f91bfad08a6965a8064fe44230aa3f87e4fa3c938f662ff4446bc682c83cb48c1a3f95cf4186688
5b93e65f6a build: remove D__STDC_FORMAT_MACROS from CPPFLAGS (fanquake)
dbfca4a815 build: require glibc 2.18+ for release builds (fanquake)
Pull request description:
This increases our runtime glibc requirement from 2.17 to 2.18. From what I can see the only platform this drops release support for is CentOS 7, which reached the end of it's "full update" support at the [end of 2020](https://wiki.centos.org/About/Product). It does receive maintenance updates until 2024, however I don't think supporting glibc 2.17 until 2024 is realistic.
It was mentioned in #22405 that our 2.17 requirement could be a bit excessive, and I tend to agree, however without a good reason to require an even newer version, I think a move from 2.17 -> 2.18 is sufficient for now. That means we get a glibc with "proper" support for `thread_local` (see below), as well as avoid having to patch dependencies to retain glibc compatibility (see #23489).
Note that anyone wanting to self-compile and target a glibc 2.17 runtime could currently build with `--disable-threadlocal`. However we wouldn't make any guarantees on how long that workaround might exist for.
glibc 2.18 was released in August 2013: https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html.
> Add support for calling C++11 thread_local object destructors on thread
and program exit. This needs compiler support for offloading C++11
destructor calls to glibc.
The last time we increased our runtime glibc requirement for release builds was in #17538 (0.20 release), where we moved from a 2.11 requirement to 2.17.
Guix builds:
```bash
bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
d21c7429dbaca3a5260ec424036e19e287c553adb2229894e59eb9b60bc2eba5 guix-build-5b93e65f6abf/output/aarch64-linux-gnu/SHA256SUMS.part
5d8e7d8b5016b694cb23bcee202819a7db63ea033e5a21c99895981f7b508184 guix-build-5b93e65f6abf/output/aarch64-linux-gnu/bitcoin-5b93e65f6abf-aarch64-linux-gnu-debug.tar.gz
db4e7b6af7d4dfa246e604f5548fd31e1ad51b810b24789f42362cd7be41cad3 guix-build-5b93e65f6abf/output/aarch64-linux-gnu/bitcoin-5b93e65f6abf-aarch64-linux-gnu.tar.gz
db97badc0ad969bcb13620fc7f087d78622f3217ee792fc28406cc083a25bcbe guix-build-5b93e65f6abf/output/arm-linux-gnueabihf/SHA256SUMS.part
58a6910362ffacd1c7df27033c25cb25f24a317f3ca909f39bb20ac552b021db guix-build-5b93e65f6abf/output/arm-linux-gnueabihf/bitcoin-5b93e65f6abf-arm-linux-gnueabihf-debug.tar.gz
9d99fd89de4798116bfe83ff1e17e10c019b3e30d2d39fd70a5bef7c937bf6d5 guix-build-5b93e65f6abf/output/arm-linux-gnueabihf/bitcoin-5b93e65f6abf-arm-linux-gnueabihf.tar.gz
254e9149d00b0e50af1c80697326ac69ab823b4e845c19f059cc229f724fbb07 guix-build-5b93e65f6abf/output/dist-archive/bitcoin-5b93e65f6abf.tar.gz
cc39947931b65960f1d32c3d53d623108a78af4bf2b3ac34b65a4c30de5feb08 guix-build-5b93e65f6abf/output/powerpc64-linux-gnu/SHA256SUMS.part
8763efeaaeea17bc526bccb050bd9da1ad2f22c7d8ec912ec0db68f4de7d4b88 guix-build-5b93e65f6abf/output/powerpc64-linux-gnu/bitcoin-5b93e65f6abf-powerpc64-linux-gnu-debug.tar.gz
de8984c519c6afc7d43e28c11f7a38b0c5c2eec676bf566448cfd0e4f6accac8 guix-build-5b93e65f6abf/output/powerpc64-linux-gnu/bitcoin-5b93e65f6abf-powerpc64-linux-gnu.tar.gz
ba73422ca3da7670435018b515bb2f8917dd23d47adb7989643b324bb47bcbf4 guix-build-5b93e65f6abf/output/powerpc64le-linux-gnu/SHA256SUMS.part
65a66250139f2379e8ff79abab0448c2a395b77bbb9f18f9ba51d2c83c598ce4 guix-build-5b93e65f6abf/output/powerpc64le-linux-gnu/bitcoin-5b93e65f6abf-powerpc64le-linux-gnu-debug.tar.gz
40e8de24f4e18af0473886cdedbc7aed2797264f8f4ed871547dd7d6e678efac guix-build-5b93e65f6abf/output/powerpc64le-linux-gnu/bitcoin-5b93e65f6abf-powerpc64le-linux-gnu.tar.gz
a42d20fd81325171f19b11f2cdf76da1d129146dfbda744125f579bb6f11a632 guix-build-5b93e65f6abf/output/riscv64-linux-gnu/SHA256SUMS.part
581379b13295665ea709f8bda7ff606a4a1d4d536f6578a22ea2c64aeea62d62 guix-build-5b93e65f6abf/output/riscv64-linux-gnu/bitcoin-5b93e65f6abf-riscv64-linux-gnu-debug.tar.gz
6dc6c6ac6116fda4596c6f577b6ecef65c552467222072e629562892a0363431 guix-build-5b93e65f6abf/output/riscv64-linux-gnu/bitcoin-5b93e65f6abf-riscv64-linux-gnu.tar.gz
ef4ee73071bd1a4d610281781eb2409dd8fe5c976ba347914e97b5cb49292db4 guix-build-5b93e65f6abf/output/x86_64-apple-darwin19/SHA256SUMS.part
c4ea3b83c7debaf2d5a5cced6408445c2cb22177b0b368df74a72612a9105600 guix-build-5b93e65f6abf/output/x86_64-apple-darwin19/bitcoin-5b93e65f6abf-osx-unsigned.dmg
e9c53a43f7f1c105f5aa8d0f8163a773a5b4a16c420ffdb2e3d0a5aab89a275f guix-build-5b93e65f6abf/output/x86_64-apple-darwin19/bitcoin-5b93e65f6abf-osx-unsigned.tar.gz
f6e67def9519895ce2bf0893dbc4279e77e61d242b64ffd7423f46439baa9642 guix-build-5b93e65f6abf/output/x86_64-apple-darwin19/bitcoin-5b93e65f6abf-osx64.tar.gz
2dac0468cda5ddd5e2aaf632228bbbde1fe98f6119c1cc0e91ab36bb7924b587 guix-build-5b93e65f6abf/output/x86_64-linux-gnu/SHA256SUMS.part
5fbb6cd4a951dc8f7d9d3ec80b8dcbce4d6cd74a4a8c532ac30a2646ca4337a5 guix-build-5b93e65f6abf/output/x86_64-linux-gnu/bitcoin-5b93e65f6abf-x86_64-linux-gnu-debug.tar.gz
2942ef6a2e67508a87566ebbea0bbbe922962fbc90df9a73d4a328953171c633 guix-build-5b93e65f6abf/output/x86_64-linux-gnu/bitcoin-5b93e65f6abf-x86_64-linux-gnu.tar.gz
0d4c30d286d040126b8418a7c7e16d94cf8fe4397f4b71250a8502bf0aa65637 guix-build-5b93e65f6abf/output/x86_64-w64-mingw32/SHA256SUMS.part
53b7f7b4243f5b9f02f91407569392ea672bb585227696cc0b63b5bc10866d8d guix-build-5b93e65f6abf/output/x86_64-w64-mingw32/bitcoin-5b93e65f6abf-win-unsigned.tar.gz
7e7c252dcfe406f47caa9593b4009d969447859f4a665a02ef4718edaf170311 guix-build-5b93e65f6abf/output/x86_64-w64-mingw32/bitcoin-5b93e65f6abf-win64-debug.zip
9cbc0780d42d6b4779ad989670757323a37151c03b4797e520a74b642b53e3dd guix-build-5b93e65f6abf/output/x86_64-w64-mingw32/bitcoin-5b93e65f6abf-win64-setup-unsigned.exe
a302b35629ac3bb21ae86905dfe521cdccd98a7e35868e12a081152adcf89bf5 guix-build-5b93e65f6abf/output/x86_64-w64-mingw32/bitcoin-5b93e65f6abf-win64.zip
```
ACKs for top commit:
laanwj:
ACK ACK ACK ACK ACK 5b93e65f6a
hebasto:
re-ACK 5b93e65f6a, only suggested changes since my [previous](https://github.com/bitcoin/bitcoin/pull/23511#pullrequestreview-806276081) review.
Tree-SHA512: e9c57b11881204ee7c4e3d474d64722bc1bd4409cf8511f2914360205158946a327aa7234bbcbae40c43c0373954d0571c28583d90c280dca53614372891ddde
4ba492052e doc: Add minimum supported Android NDK version (Hennadii Stepanov)
6393bdcd53 doc: Move Android dependencies guide into `build-android.md` (Hennadii Stepanov)
ac323a7222 build: Switch to llvm buinutils for Android builds (Hennadii Stepanov)
Pull request description:
The new Long Term Support release of the Android NDK is [available](https://groups.google.com/g/android-ndk-announce/c/MS6Qoub0DKE/m/Zfp5Ys8eAAAJ) since 2021-08-11:
> As r23 is the new LTS, the support windows for r21 and r22 have now ended.
On master (8ae4ba481c), dependency build fails because it expects GNU Binutils are present in the Android NDK. In [fact](https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#binutils):
> GNU Binutils remains available up to and including r22. All binutils tools with the exception of the assembler (GAS) were removed in r23. GAS was removed in r24.
This PR switches our depends build system to llvm binutils. The usage of `llvm-ar` and `llvm-ranlib` tools effectively makes r21 the minimum supported version of NDK.
With this PR:
- building depends against NDK r23 LTS now is possible with `NO_QT=1`
- building the `qt` package in depends against NDK r23 LTS still fails:
```
Creating qmake...
...
ERROR: Cannot detect Android NDK toolchain.
Please use -android-toolchain-version to specify it.
```
The issue with the `qt` package is going to be addressed in another PR.
ACKs for top commit:
fanquake:
ACK 4ba492052e
Tree-SHA512: cdc8f95ff9a3ad7f12eb55b9ea18b6b6b800d4cceff7e0321985be6e39d15a2b2ea5b1592972307d76d111292a0ed58fd287e5ca285e2f6868b42a286536d310
From what I can see the only platform this drops support for is CentOS
7. CentOS 7 reached the end of it's "full update" support at the end of
2020. It does receive maintenance updates until 2024, however I don't
think supporting glibc 2.17 until 2024 is realistic. Note that anyone
wanting to self-compile and target a glibc 2.17 runtime could build with
--disable-threadlocal.
glibc 2.18 was released in August 2013.
https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html
410f99faed build_msvc/bitcoin_config.h is generated using build_msvc/msvc-autogen.py (CallMeMisterOwl)
Pull request description:
Added a function that parses version information from `configure.ac` into `build_msvc/bitcoin_config.h`. This is done by default in `msvc-autogen.py`, so manual changing of `build_msvc/bitcoin_config.h` is no longer required.
In addition to that I updated the Release Process doc.
Following values are updated:
-**CLIENT_VERSION_BUILD**
-**CLIENT_VERSION_IS_RELEASE**
-**CLIENT_VERSION_MAJOR**
-**CLIENT_VERSION_MINOR**
-**COPYRIGHT_YEAR**
-**PACKAGE_STRING**
-**PACKAGE_VERSION**
fixes#23073
ACKs for top commit:
laanwj:
Code review and lightly tested ACK 410f99faed
Tree-SHA512: 6b324ec8680b70c405c46a0fcd61836d1b57bb3eaef2cc36bb1e9856890f0423c201a8fdddc95ca0fb5b3dade71ff6d4d14351c606b3351eef2faa0c70bca38a
29173d6c6c ubsan: add minisketch exceptions (Cory Fields)
54b5e1aeab Add thin Minisketch wrapper to pick best implementation (Pieter Wuille)
ee9dc71c1b Add basic minisketch tests (Pieter Wuille)
0659f12b13 Add minisketch dependency (Gleb Naumenko)
0eb7928ab8 Add MSVC build configuration for libminisketch (Pieter Wuille)
8bc166d5b1 build: add minisketch build file and include it (Cory Fields)
b2904ceb85 build: add configure checks for minisketch (Cory Fields)
b6487dc4ef Squashed 'src/minisketch/' content from commit 89629eb2c7 (fanquake)
Pull request description:
This takes over #21859, which has [recently switched](https://github.com/bitcoin/bitcoin/pull/21859#issuecomment-921899200) to my integration branch. A few more build issues came up (and have been fixed) since, and after discussing with sipa it was decided I would open a PR to shepherd any final changes through.
> This adds a `src/minisketch` subtree, taken from the master branch of https://github.com/sipa/minisketch, to prepare for Erlay implementation (see #21515). It gets configured for just supporting 32-bit fields (the only ones we're interested in in the context of Erlay), and some code on top is added:
> * A very basic unit test (just to make sure compilation & running works; actual correctness checking is done through minisketch's own tests).
> * A wrapper in `minisketchwrapper.{cpp,h}` that runs a benchmark to determine which field implementation to use.
Only changes since my last update to the branch in the previous PR have been rebasing on master and fixing an issue with a header in an introduced file.
ACKs for top commit:
naumenkogs:
ACK 29173d6c6c
Tree-SHA512: 1217d3228db1dd0de12c2919314e1c3626c18a416cf6291fec99d37e34fb6eec8e28d9e9fb935f8590273b8836cbadac313a15f05b4fd9f9d3024c8ce2c80d02
fanquake
