The Windows binaries are particularly big when they contain debug
info, closing in on 500mb. Add a note to the Windows build instructions
about using `--strip`.
f5d8b66a8c Squashed 'src/minisketch/' changes from eb37a9b8e7..d1e6bb8bbf (fanquake)
Pull request description:
Includes:
* https://github.com/bitcoin-core/minisketch/pull/92
ACKs for top commit:
hebasto:
ACK 4fde88bc46, I've updated the subtree locally and got zero diff with this PR.
Tree-SHA512: 0ddaa6b64ca14da244d455594bc122a059fd1d199d28a7a78f266e352811568bd0f30d3b1e5e5d859f92753d3979831c095e3f6078f0ba2c909b1566a0e74a0c
We shouldn't have | at the end of the last clause, as this will make it match
the empty string too (so effectively everything starting with Satoshi: matches).
While doing this, put the | at the beginning of every line of regex rather than
the end, to make it easier to update in the future without accidentally running
into this problem again.
d76647eb8f ci: use LLVM 20.1.0 for MSAN (fanquake)
Pull request description:
Now that the release is out, stop using rc1.
ACKs for top commit:
l0rinc:
utACK d76647eb8f
Sjors:
ACK d76647eb8f
Tree-SHA512: 2eefad118dd617c3e9554caee1549965fc4acc437dbef1252c1912faea57ccbfcb39f879911f27f4274931c1d8723b9c7f981aafa6958e70d4371f16c368c627
In Base58 fuzz the two roundtrips are merged now, the new `decode_input` switches between a completely random input and a valid encoded one, to make sure the decoding passes more often.
The `max_ret_len` can also exceed the original length now and is being validated more thoroughly.
Co-authored-by: maflcko <6399679+maflcko@users.noreply.github.com>
Co-authored-by: marcofleon <marleo23@proton.me>
They seem to cause timeouts:
> Issue 397734700: bitcoin-core:base58check_encode_decode: Timeout in base58check_encode_decode
The `encoded_string.empty()` check was corrected here to `decoded.empty()` to make sure the `(0, decoded.size() - 1)` range is always valid.
Co-authored-by: maflcko <6399679+maflcko@users.noreply.github.com>
Co-authored-by: marcofleon <marleo23@proton.me>
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
e181bda061 guix: Apply all codesignatures to Windows binaries (Ava Chow)
aafbd23fd9 guix: Apply codesignatures to all MacOS binaries (Ava Chow)
3656b828dc contrib: Sign all Windows binaries too (Ava Chow)
31d325464d contrib: Sign and notarize all MacOS binaries (Ava Chow)
710d5b5149 guix: Update signapple (Ava Chow)
e8b3c44da6 build: Include all Windows binaries for codesigning (Ava Chow)
dd4ec840ee build: Include all MacOS binaries for codesigning (Ava Chow)
4e5c9ceb9d guix: Rename Windows unsigned binaries to unsigned.zip (Ava Chow)
d9d49cd533 guix: Rename MacOS binaries to unsigned.tar.gz (Ava Chow)
c214e5268f guix: Rename unsigned.tar.gz to codesigning.tar.gz (Ava Chow)
Pull request description:
I have updated signapple to notarize MacOS app bundles without adding any additional dependencies. Further, it can also sign and apply detached signatures to standalone binaries.
As such, we can use signapple to perform the notarization and stapling steps so that MacOS will run the app bundle after it is installed. `detached-sig-create.sh` is updated to have a notarization step and to download the ticket which will be included in the detached signatures. The workflow is largely unchanged for the MacOS codesigners except for the additional requirement of having an App Store Connect API key and Team UUID, instructions for which can be found at https://github.com/achow101/signapple/blob/master/docs/notarization.md. For guix builders, the workflow is unchanged.
Additionally, the standalone binaries packaged in the MacOS `.tar.gz` and Windows `.zip` will now be codesigned. `detached-sig-create.sh` was updated to handle these, so the workflow for both MacOS and Windows codesigners remains unchanged. For guix builders, the workflow is also unchanged.
Because those binaries will how have codesigned and unsigned versions, the build command is modified to output `-unsigned.{tar.gz,zip}` archives containing the binaries. Since this happens to conflict with the tarball used for codesigning, the codesigning tarball was renamed to `-codesigning.tar.gz`. Both MacOS and Windows codesigners will need to adjust their workflows to account for the new name.
Fixes#15774 and #29749
ACKs for top commit:
Sjors:
Tested ACK e181bda061
davidgumberg:
Tested ACK e181bda061.
pinheadmz:
tested ACK e181bda061
Tree-SHA512: ce0e2bf38e1748cdaa0d13be6f61c3289cd09cfb7d071a68b0b13d2802b3936c9112eda6e4c7b29c535c0995d56b14871442589cdcea2e7707e35c1b278b9263
d1e6bb8bbf Merge bitcoin-core/minisketch#92: doc: rename from sipa to bitcoin-core
b7b7dd0ec8 doc: rename from sipa to bitcoin-core
git-subtree-dir: src/minisketch
git-subtree-split: d1e6bb8bbf8ef104b9dd002cab14a71b91061177
972b604dc4 doc: update location of minisketch repository (fanquake)
Pull request description:
This repository is now at https://github.com/bitcoin-core/minisketch.
ACKs for top commit:
hebasto:
ACK 972b604dc4.
theStack:
ACK 972b604dc4
Tree-SHA512: a164f97700e73b284429993f9639d1d4eab23cc09ded3104be392d5d259297c2906906a565ffa8848a495e8f35cbbe18ba4155fe1d16cda0406ac3c75f9d9a62
75486c8ed8 doc: update fuzz instructions when on macOS (Max Edwards)
Pull request description:
Fixes: #31049
Updates the instructions for fuzzing on macOS to use `lld` instead of `ld`.
Tested instructions on M1 Mac running 14.6.1
ACKs for top commit:
l0rinc:
ACK 75486c8ed8
brunoerg:
ACK 75486c8ed8
hebasto:
ACK 75486c8ed8, tested on macOS 15.3.1 (Apple M1) + Clang 19.1.7.
Tree-SHA512: 2c5645d78fce1644964dee55c8ca6a6549bfd4f4a9a5719bbe49264f7216f0267c27999e23402a47eecbc8502985d812b986bf6850a5d63d110bdb98769f23c2
18749efb07 scripted-diff: rename libmultiprocess repository (fanquake)
Pull request description:
For when we shift `libmultiprocess` into the `bitcoin-core` organisation.
ACKs for top commit:
Sjors:
tACK 18749efb07
hebasto:
ACK 18749efb07.
Tree-SHA512: df361e239da072dba2574e90231bbf8c4daf906786a838fe63761d38d5624510dbeeb6308567dc32321bd3bc76f1117606c8eb2c22e299aa164786ec342bd4b3
c718bffc36 build: don't use ccache with MSVC (fanquake)
Pull request description:
Set `WITH_CCACHE` to `OFF` for MSVC, so it doesn't show as `ON` in the configure summary.
Fixes#31771.
ACKs for top commit:
hebasto:
ACK c718bffc36, I have reviewed the code and it looks OK.
Tree-SHA512: cf20b36a496a446051d0586c55d05a9133dce26a958e6b39b510094c56014275b866806c88be40ffa918b4280970c082b981b4e52e4bfdb8cec1556f666898fc
This change builds libraries with -fsanitize=fuzzer-no-link instead of
-fsanitize=fuzzer when the cmake -DSANITIZERS=fuzzer option is specified. This
is necessary to make fuzzing and IPC cmake options compatible with each other
and avoid CI failures in #30975 which enables IPC in the fuzzer CI build:
https://cirrus-ci.com/task/5366255504326656?logs=ci#L2817https://cirrus-ci.com/task/5233064575500288?logs=ci#L2384
The failures can also be reproduced by checking out #31741 and building with
`cmake -B build -DBUILD_FOR_FUZZING=ON -DSANITIZERS=fuzzer -DENABLE_IPC=ON`
with this fix reverted.
The fix updates the cmake build so when -DSANITIZERS=fuzzer is specified, the
fuzz test binary is built with -fsanitize=fuzzer (so it can use libFuzzer's
main function), and libraries are built with -fsanitize=fuzzer-no-link (so they
can be linked into other executables with their own main functions).
Previously when -DSANITIZERS=fuzzer was specified, -fsanitize=fuzzer was
applied to ALL libraries and executables. This was inappropriate because it
made it impossible to build any executables other than the fuzz test executable
without triggering link errors:
- "multiple definition of `main'"
- "undefined reference to `LLVMFuzzerTestOneInput'"
if they depended on any libraries instrumented for fuzzing.
This was especially a problem when the ENABLE_IPC option was set because it
made building the mpgen code generator impossible so nothing else that depended
on generated sources, including the fuzz test binary, could be built either.
This commit was previously part of
https://github.com/bitcoin/bitcoin/pull/31741 and had some discussion there
starting in
https://github.com/bitcoin/bitcoin/pull/31741#pullrequestreview-2619682385
02fae33635 doc: add assumeutxo chainparams to release proc (willcl-ark)
Pull request description:
This should ideally be bumped every major (and perhaps even minor?) release to avoid falling too far behind, and therefore keeping this feature as useful as it can be.
Document in release-process.md to avoid forgetting to do this.
ACKs for top commit:
achow101:
ACK 02fae33635
glozow:
ACK 02fae33635
Tree-SHA512: 1c570b476a2c1369cde20965a762a4bce76fc27e7cf2704032132c9679ac1bc003d5dcc5b2bf39625f1b92b182254bec60743e52858ef89428df2b90ff4fb804
fff4f93dff doc: Bring reduce-memory.md up to date (laanwj)
Pull request description:
Update default number of RPC threads to 16 (#31215) and remove reference to very old version of bitcoin core.
Let me know if you notice other mismatches with current defaults.
ACKs for top commit:
achow101:
ACK fff4f93dff
brunoerg:
ACK fff4f93dff
TheCharlatan:
ACK fff4f93dff
vasild:
ACK fff4f93dff
Tree-SHA512: 14d91da1f86c8b460828a6e4ae9151ec430cbbaefa85d258c574b5e340cbf64244de981d5b3f37a0d97aafe872f3edb100596fc9e2b11c0df7874b1da8054a55
14f1674855 chainparams: add mainnet assumeutxo param at height 880_000 (Sjors Provoost)
Pull request description:
#31940 suggests adding a snapshot at every major release.
This snapshot should be suitable for v29. I picked the most recent multiple of 10K blocks.
You can either download this torrent:
```
magnet:?xt=urn:btih:559bd78170502971e15e97d7572e4c824f033492&dn=utxo-880000.dat&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969
```
Or generate the snapshot yourself:
```sh
bitcoin-cli -rpcclienttimeout=0 -named dumptxoutset utxo-880000.dat rollback=880000
```
The SHA-256 hash should be:
```
shasum -a 256 utxo-880000.dat
43b3b1ad6e1005ffc0ff49514d0ffcc3e3ce671cc8d02da7fa7bac5405f89de4
```
And then load it on a fresh node during IBD with:
```
bitcoin-cli -rpcclienttimeout=0 loadtxoutset utxo-880000.dat
```
Note that it's more performant to turn off networking while the snapshot is loading, see #29993:
```sh
bitcoin-cli setnetworkactive false
```
Once the snapshot is loaded:
```sh
bitcoin-cli setnetworkactive true
```
And enjoy a speedy ride to the tip.
ACKs for top commit:
achow101:
ACK 14f1674855
fjahr:
tACK 14f1674855
hodlinator:
ACK 14f1674855
rkrux:
Concept ACK 14f1674855
polespinasa:
ACK 14f1674855
Tree-SHA512: e7ed3e8ce3a247614545ecd3254a91814d7f87b3ca1be46df3b9a4c1e6353b46c82ab97d9fc9c5bed8938f28a6a61e6b70baa7c9649fe5da0f2f390b7932f15e
In the assumeutxo functional tests, the final test case with alternated UTxO data tests the error
raised when deserializing a snapshot that contains a coin with an amount not in range (<0 or
>MAX_MONEY).
The current malleation uses an undocumented byte string and offset which makes it hard to maintain.
In addition, the undocumented offset is set surprisingly high (39 bytes is well into the
serialization of the amount which starts at offset 36). Similarly the value is surprisingly small,
presumably one was adjusted for the other. But there is no comment explaining how they were chosen,
why not in a clearer manner and what they are supposed to represent.
Instead replace this seemingly magic value with a clear one, MAX_MONEY + 1, serialize the whole
value for the amount field at the correct offset, and document the whole thing for the next person
around.
Transifex interprets the "-0" substring as a number in translatable
strings. Since not all translations preserve "-0," this triggers a
corresponding warning. While this warning could be disabled globally, it
is more reasonable to adjust the original string instead.
