Addnode (manual) peers connected to us via the cjdns network are currently not
detected by CConnman::GetAddedNodeInfo(), i.e. fConnected is always false.
This causes the following issues:
- RPC `getaddednodeinfo` incorrectly shows them as not connected
- CConnman::ThreadOpenAddedConnections() continually retries to connect them
Github-Pull: #30085
Rebased-From: 684da97070
Without explicitly declaring the move, these UniValues get copied,
causing increased memory usage. Fix this by explicitly moving the
UniValue objects.
Used by `rest_block` and `getblock` RPC.
Github-Pull: #30094
Rebased-From: b77bad309e
The 32 to 64-bit time_t transition causes a build failure in the built-in
zlib about conflicting _TIME_BITS and _FILE_OFFSET_BITS.
Note that zlib doesn't use time_t at all, so it is a false alarm.
Take the following patch from upstream zlib:
a566e156b3.patch
Closes#29980.
Github-Pull: #29985
Rebased-From: 2e266f33b5
Pretty much all library packages were renamed in the 64-bit time_t
migration to add `t64` (even on 64-bit platforms).
Instead of complicating the doc with conditional package names, suggest
installing the `-dev` packages which still have the same name, and
besides that, are the right way to go about it as they contain the
"user facing" C++ headers needed to build against Qt5.
For Fedora, devel packages are already suggested.
This affects Ubuntu 24.04 and Debian Testing.
Github-Pull: #29764
Rebased-From: a3c6a13cb2
The script provided for signature might be externally provided, for
instance by way of 'finalizepsbt'. Therefore the script might be
ill-crafted, so don't assume pubkeys are always 32 bytes.
Thanks to Niklas for finding this.
Github-Pull: #29853
Rebased-From: 4d8d21320e
The issue is that compilation is done with `x86_64-w64-mingw32-g++-posix`,
but then linking is done with `x86_64-w64-mingw32-g++`.
I'm guessing this has been broken since #24131
(01d1845a80), but have not checked.
Fixes#29734.
Unblocks #29527 (now DEBUG=1 builds can be tested).
Github-Pull: #29747
Rebased-From: b7e7e727ab
cc0553d0d6 [doc] add manual pages for 26.1 (glozow)
785242dd4c [doc] update release notes 26.1 (glozow)
5f06dcf9c9 [build] bump version to 26.1 final (glozow)
b53bf22c72 ci, macos: Use `--break-system-packages` with Homebrew's python (Hennadii Stepanov)
324e562399 ci: Add workaround for Homebrew's python link error (Hennadii Stepanov)
Pull request description:
Final changes for `v26.1`.
Bins for rc2 have been available for 10 days and I haven't seen any bug reports or new things to add.
Includes #29610 backport for the CI, which has no effect on what goes into the release.
Website PR: https://github.com/bitcoin-core/bitcoincore.org/pull/1009
ACKs for top commit:
hebasto:
ACK cc0553d0d6.
fanquake:
ACK cc0553d0d6
stickies-v:
ACK cc0553d0d6 (modulo CI passing)
Tree-SHA512: d032157c7cdf07a474e40b947f7e51bfc6a8e280e43345522bad67b6ad449d473f29bf03ee845b2e403693c1c81078589d042337c895eceb8a59cb4340432887
We preemptively perform a block mutation check before further processing
a block message (similar to early sanity checks on other messsage
types). The main reasons for this change are as follows:
- `CBlock::GetHash()` is a foot-gun without a prior mutation check, as
the hash returned only commits to the header but not to the actual
transactions (`CBlock::vtx`) contained in the block.
- We have observed attacks that abused mutated blocks in the past, which
could have been prevented by simply not processing mutated blocks
(e.g. https://github.com/bitcoin/bitcoin/pull/27608).
Github-Pull: #29412
Rebased-From: 49257c0304
The MinGW-w64 toolchain links executables to the old msvcrt C Runtime
Library that does not support the `x` modifier for the _wfopen()
function.
Github-Pull: #29357
Rebased-From: d2fe90571e
1e956439eb rpc: keep .cookie if it was not generated (Roman Zeyde)
Pull request description:
v26 introduced a regression in that starting a `bitcoind` twice may have the second instance delete the cookie file of the first, making it impossible to communicate with it.
Not a big deal but it's annoying, only an issue for 26.0, and the patch is trivial.
ACKs for top commit:
glozow:
lgtm ACK 1e956439eb
Tree-SHA512: 0e4b18aebaaf284944f1709b238c8c0acce5e8997409e0c278a5a30ac221ac1ff1d3ad31fbf2ac15b03bf7582891e07a7a2cf00f13cb596aa9512566b9320c23
Otherwise, starting bitcoind twice may cause the `.cookie`
file generated by the first instance to be deleted by the
second instance shutdown (after failing to obtain a lock).
Github-Pull: bitcoin/bitcoin#28784
Rebased-From: 7cb9367157
This change is a result if pulling the recent translations
from the Transifex website using the
bitcoin-maintainer-tools/update-translations.py tool.
A few manual adjustments were made:
- skipped removing of `bitcoin_af.ts`
- skipped removing of `bitcoin_ar.ts`
- skipped adding of `bitcoin_ru_RU.ts` (`bitcoin_ru.ts` is already
present)
LLVM Clang >=16.0 and Apple Clang >=15.0 do not recognize
`-Xclang -internal-isystem/usr/local/include` anymore.
For example, see: cbbe1d4454
Github-Pull: #29195
Rebased-From: 8decc5c726
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer.
Github-Pull: #29127
Rebased-From: 4fdd836db9
Test that wallet rescans process transactions topologically, even if a
parent's entry into the mempool is later than that of its child.
This behavior is important because IsFromMe requires the ability to look
up a transaction's inputs.
Co-authored-by: furszy <matiasfurszyfer@protonmail.com>
Github-Pull: #29179
Rebased-From: df30247705
