66b2b109eb depends: xcb-proto 1.15.2 (fanquake)
Pull request description:
Resolves build failures under Python 3.12, i.e building on rawhide:
```bash
make[3]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p '/bitcoin/depends/work/staging/aarch64-unknown-linux-gnu/xcb_proto/1.14.1-4a91ac9dc41/bitcoin/depends/aarch64-unknown-linux-gnu/lib/python3.12/site-packages/xcbgen'
/usr/bin/install -c -m 644 __init__.py error.py expr.py align.py matcher.py state.py xtypes.py '/bitcoin/depends/work/staging/aarch64-unknown-linux-gnu/xcb_proto/1.14.1-4a91ac9dc41/bitcoin/depends/aarch64-unknown-linux-gnu/lib/python3.12/site-packages/xcbgen'
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'imp'
make[3]: *** [Makefile:271: install-pkgpythonPYTHON] Error 1
```
`imp` was removed in 3.12: https://docs.python.org/3/library/imp.html.
Github-Pull: #28097
Rebased-From: 7cb88c8b46
Also being backported for 25.x in #28047.
ACKs for top commit:
hebasto:
ACK 66b2b109eb
Tree-SHA512: 5364c5ced3004bc08a9c8f96e2b3abae3e31b3f0e7b1d10f83ff997f19b314d4d14c2a780ed02e793771c23091f8f02137cf7f5404627f2bd218c8726ae3228f
89a5a416de doc: update release notes for 24.1 (fanquake)
b36dff9fa8 doc: update manual pages for 24.1 (fanquake)
8af2d2f762 build: bump version to 24.1 final (fanquake)
Pull request description:
Final changes for `v24.1`.
PR for bitcoincore.org is here: https://github.com/bitcoin-core/bitcoincore.org/pull/968.
ACKs for top commit:
josibake:
ACK 89a5a416de
hebasto:
ACK 89a5a416de, I have reviewed the code and it looks OK.
stickies-v:
ACK 89a5a416de
Tree-SHA512: 6eb7d30790b50cfc7232cf7c69b5c8b1fbb943cc715d275ff4d8c2ade93d82bf2bc659b82a06b8453e2e0382e9d375aee2c71d0fee44285f9eb8a029980a29d3
If transactions are being added to the mempool at a rate faster than 7tx/s
(INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can
become relatively large. If this happens, increase the number of txids
we include in an INV message (normally capped at 35) by 5 for each 1000
txids in the queue.
This will tend to clear a temporary excess out reasonably quickly; an
excess of 4000 invs to send will be cleared down to 1000 in about 30
minutes, while an excess of 20000 invs would be cleared down to 1000 in
about 60 minutes.
Github-Pull: #27610
Rebased-From: 5b3406094f
We use CompareDepthAndScore to choose an order of txs to inv. Rather
than sorting txs that have been evicted from the mempool at the end
of the list, sort them at the beginning so they are removed from
the queue immediately.
Github-Pull: #27610
Rebased-From: 228e9201ef
03a16a1da0 doc: update release notes for 24.1rc2 (fanquake)
f344c66053 doc: update manual pages for v24.1rc2 (fanquake)
4451e89988 build: bump version to v24.1rc2 (fanquake)
Pull request description:
rc1 (tagged > a month ago) was mostly a no-op, due to lack of binaries. While some are up now, [albeit at the wrong URL](https://bitcoincore.org/bin/bitcoin-24.1rc1/), there seems no point continuing the rc1 cycle, when we already have additional changes backported (#27474), and we've also received no bug reports/feedback from anyone who did test.
So bump the version, and cut an rc2.
ACKs for top commit:
achow101:
ACK 03a16a1da0
gruve-p:
ACK 03a16a1da0
hebasto:
ACK 03a16a1da0, I have reviewed the code and it looks OK.
Tree-SHA512: f49072149ecabb02b034b1c4d7319a80f93a8c7a29a2b7ec27dff0c257742d08d48fbf266399ce71769cec992902b7d53fc26bb5ffc8681728dc8685cbba25d9
- clarify that there can be multiple warning messages
- specify the correct wallet action
- describe the use of newlines as delimiters
Github-Pull: #27279
Rebased-From: f73782a903
`evhttp_uri_parse` can return a nullptr, for example when the URI
contains invalid characters (e.g. "%").
`GetQueryParameterFromUri` passes the output of `evhttp_uri_parse`
straight into `evhttp_uri_get_query`, which means that anyone calling
a REST endpoint in which query parameters are used (e.g. `rest_headers`)
can cause a segfault.
This bugfix is designed to be minimal and without additional behaviour change.
Github-Pull: #27468
Rebased-From: 11422cc572
Compiling bdb with clang-16 on aarch64 (hardware) currently fails:
```bash
make -C depends/ bdb CC=clang CXX=clang++
...
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
```
Looking at config.log we've got:
```bash
configure:18704: checking for mutexes
configure:18815: clang -o conftest -pipe -std=c11 -O2 -Wno-error=implicit-function-declaration -Wno-error=format-security -I/bitcoin/depends/aarch64-unknown-linux-gnu/include -D_GNU_SOURCE -D_REENTRANT -L/bitcoin/depends/aarch64-unknown-linux-gnu/lib conftest.c -lpthread >&5
conftest.c:45:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
main() {
^
int
conftest.c:50:2: warning: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
exit (
^
conftest.c:50:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
```
Clang-16 changed `-Wimplicit-function-declaration` and `-Wimplicit-int`
warnings into errors, see:
https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.
> The -Wimplicit-function-declaration and -Wimplicit-int warnings now
> default to an error in C99, C11, and C17. As of C2x, support for implicit
> function declarations and implicit int has been removed, and the
> warning options will have no effect. Specifying -Wimplicit-int in
> C89 mode will now issue warnings instead of being a noop.
Github-Pull: #27462
Rebased-From: f8b8458276
a2f8a839d9 qt: 24.1rc1 translations update (Hennadii Stepanov)
Pull request description:
This PR pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool.
According to our [Release Process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-release-candidate), it is supposed to be merged before `v24.1rc1` tagging (#27247).
Will keep this PR updated regularly until merging.
The Dutch translation `bitcoin_nl.ts` has been damaged, therefore its changes were rejected manually.
ACKs for top commit:
stickies-v:
I'm not familiar with the translations process and I couldn't verify that `bitcoin_nl.ts` is damaged, but if this constitutes sufficient review then ACK a2f8a839d9
Tree-SHA512: d914d158c4a4b62a2c37040f5cc0602ef749a7bf658af0e364a0d2cb52b802a00863496751cf3db42d74e8950c49969ee9dd03c5c3fee79860113389f36ee483
Since migration reloads the wallet, the wallet will always be locked
unless the passphrase is given. migratewallet can now take the
passphrase in order to unlock the wallet for migration.
Github-Pull: #26595
Rebased-From: 7fd125b27d
An overload of MigrateLegacyToDescriptor is added which takes the wallet
name. The original that took a wallet pointer is still available, it
just gets the name, closes the wallet, and calls the new overload.
Github-Pull: #26595
Reabsed-From: dbfa345403
In the case of `i2pacceptincoming=0` we use transient addresses
(destinations) for ourselves for each outbound connection. It may
happen that we
* create the session (and thus our address/destination too)
* fail to connect to the particular peer (e.g. if they are offline)
* dispose the unused session.
This puts unnecessary load on the I2P network because session creation
is not cheap. Is exaggerated if `onlynet=i2p` is used in which case we
will be trying to connect to I2P peers more often.
To help with this, save the created but unused sessions and pick them
later instead of creating new ones.
Alleviates: https://github.com/bitcoin/bitcoin/issues/26754
Github-Pull: #26837
Rebased-From: b906b64eb7
When an encrypted wallet is locked (for instance via the
RPC `walletlock`), the docs indicate that the key is
removed from memory. However, the vector (with a secure
allocator) is merely cleared. This allows the key to persist
indefinitely in memory. Instead, manually fill the bytes with
zeroes before clearing.
Github-Pull: #27080
Rebased-From: 3a11adc700
The way that the main overview page limits the number
of transactions displayed (currently 5) is not
an appropriate use of Qt. If it's run with a DEBUG
build of Qt, it'll result in a segfault in certain
relatively common situations. Instead of artificially
limiting the rowCount() in the subclassed proxy
filter, we hide/unhide the rows in the displaying
QListView upon any changes in the sorted proxy filter.
Github-Pull: bitcoin-core/gui/pull/704
Rebased-From: 08209c039f
The previous logic would call it once for serializing into the filestream,
and then again for serializing into the hasher. If AddrMan was changed
in between these calls by another thread, the resulting peers.dat would
be corrupt with non-matching checksum and data.
Fix this by using HashedSourceWriter, which writes the data
to the underlying stream and keeps track of the hash in one go.
Github-Pull: #26909
Rebased-From: 5eabb61b23
