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: b77bad309e92f176f340598eec056eb7bff86f5f
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: 2e266f33b5d2be5c233c2c692481f75785714fa1
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: a3c6a13cb23999fa70c428f1229acbf1b3883f11
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: 4d8d21320eba54571ff63931509cd515c3e20339
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
(01d1845a80ae48d741deea695ddce95d940ab0d8), but have not checked.
Fixes#29734.
Unblocks #29527 (now DEBUG=1 builds can be tested).
Github-Pull: #29747
Rebased-From: b7e7e727abd86104ee58beb648a94e2f453d1f6d
To avoid issues with DNS blacklisting, I've setup a separate domain for my DNS seed.
Github-Pull: #29691
Rebased-From: 4f273ab4360c9aa72c2feb78787e1811ab58dc16
cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1 [doc] add manual pages for 26.1 (glozow)
785242dd4ca5b05155f67a8ab097dc35ee183559 [doc] update release notes 26.1 (glozow)
5f06dcf9c9481ab8f034aece447e12da67ab7ce7 [build] bump version to 26.1 final (glozow)
b53bf22c722309cba923b90840c1e48b98f553c9 ci, macos: Use `--break-system-packages` with Homebrew's python (Hennadii Stepanov)
324e56239960308333ac9e46f1c815020f0b149f 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 cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1.
fanquake:
ACK cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1
stickies-v:
ACK cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1 (modulo CI passing)
Tree-SHA512: d032157c7cdf07a474e40b947f7e51bfc6a8e280e43345522bad67b6ad449d473f29bf03ee845b2e403693c1c81078589d042337c895eceb8a59cb4340432887
Homebrew's python@3.12 is marked as externally managed (PEP 668),
necessitating different approaches for installing Python packages.
For more details, please refer to https://github.com/orgs/Homebrew/discussions/3404.
Github-Pull: #29610
Rebased-From: acc06bc91f80ddf4e015dcdf0b984bbdbfcb5ca3
Promoting Homebrew's python@3.12 to the default python3 breaks symbolic
links on macOS x86_64.
This change adds a workaround for that issue.
Also see: https://github.com/actions/runner-images/issues/9471 etc.
Github-Pull: #29610
Rebased-From: ae5f72027f1776f815a6637c594f0f725a6ccb55
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: 49257c0304828a185c273fcb99742c54bbef0c8e
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: d2fe90571e98e02617682561ea82acb1e2647827
1e956439eb86de7a455560c349370684f4e54561 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 1e956439eb86de7a455560c349370684f4e54561
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: 7cb9367157eb42ee06bc6fa024522cc14a80138d
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: 8decc5c726caca2381cffbd1b3585862421f5b8e
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: 4fdd836db92e789c98b9e68398ca931a968cc9c3
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: df30247705940c50c5eaafd74e2abbeb8b0cec07
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.
Github-Pull: #29179
Rebased-From: c3d02be536ac3f35c10efa03653186a17ebbfc12
