📝 vostrnad opened a pull request: "doc: Add release note for coinstatsindex in pruned mode"
(https://github.com/bitcoin/bitcoin/pull/28909)
#21726 enabled using `coinstatsindex` in pruned mode. I recently had to update one of my nodes from 23.0 because of this and noticed that this isn't mentioned in the release notes for 24.0.1.

<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide
...

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817630948)
Is this difference in reported cache size expected:
- in master @ 3a93957a5dc97cb2fd0656d1e2451ebef57204df (pre-[PR25325](https://github.com/bitcoin/bitcoin/pull/25325)):
```
UpdateTip: new best=00000000000001bc255d63d3e82af7638566a5fbaadb6d5bdc41d0731a23d1ea height=209285 version=0x00000001 log2_work=69.067375 tx=9192843 date='2012-11-24T00:09:17Z' progress=0.010297 cache=376.0MiB(3276665txo)
Cache size (394377008) exceeds total space (394371840)
```
- in master @ 5aa0c82ccd6ceb4a141686fc
...

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817631083)
> @hebasto could you try another patch? [martinus@04fb0b3](https://github.com/martinus/bitcoin/commit/04fb0b35cf18d5805d58595c27f027fae4428e62) This removes the placement new that didn't reuse the returned pointer, which technically has always been illegal

Tested. No behavior change. Still OOM.

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817643679)
> Is this difference in the reported cache size expected

Yes, when the pool is used the flushes happen at different times because more transactions are cached, so the number of cached transaction at certain heights can be completely different

> Tested. No behavior change. Still OOM.

Thanks for testing! Hm, I'm out of ideas for now... I don't see anything in the code that could cause this. My only suspicion is that for some reason on ARM the freed memory from the pool is not reused, but
...

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817662547)
> > Is this difference in the reported cache size expected
>
>
>
> Yes, when the pool is used the flushes happen at different times because more transactions are cached, so the number of cached transaction at certain heights can be completely different

The point is that the former log shows the first flush. In the latter one, there were no flushes by that point at all.

💬 Farnoosh85 commented on issue "test: `wallet_importdescriptors.py --descriptors` failure":
(https://github.com/bitcoin/bitcoin/issues/27282#issuecomment-1817733980)
27229

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817748721)
> The point is that the former log shows the first flush. In the latter one, there were no flushes by that point at all.

That's ok, with pool it flushes later. But on second glance, the cache size is incorrect: `cache=26.3MiB(3276665txo)`
That's not possible, there's cache can only be 26.3MiB with 3276665tx in it. So this looks like the cache size estimation doesn't work for some reason. Can you post the full log?

📝 cloudbed1 opened a pull request: "Create Web-Scale Blockchain for fast,"
(https://github.com/bitcoin/bitcoin/pull/28910)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

✅ cloudbed1 closed a pull request: "Create Web-Scale Blockchain for fast,"
(https://github.com/bitcoin/bitcoin/pull/28910)

📝 achow101 locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/28910)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

⚠️ fujicoin opened an issue: "Signet mining is not possible when using descriptor wallet"
(https://github.com/bitcoin/bitcoin/issues/28911)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Signet mining is not possible when using descriptor wallet.
The error message is "PSBT signing failed"

Errors were confirmed in the following two cases.
1. In an environment where mining is performed using a legacy wallet, the wallet is changed to a descriptor type using the "migratewallet" command.
2. A case where the private key descriptor of the address that generated the signetch
...

💬 martinus commented on issue "v26.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/28718#issuecomment-1817780006)
The log `[...] cache=232.0MiB(31044257txo)` indicates that here too something might be wrong with the `DynamicMemory` calculation. when having 31 million txo in memory cache size should be much higher.

💬 helpau commented on issue "Sync slow":
(https://github.com/bitcoin/bitcoin/issues/26063#issuecomment-1817784916)
Here's what I did to get logs with [lock] entries
1)Downloaded the release 25.1 source code, installed VS 2022
2)Installed qt with the -debug-and-release parameter
3)Installed the dependencies via vcpkg
4)Specified DEBUG_LOCKCONTENTION parameter for libbitcoin_utul project, started Debug solution build, ran bitcoin-qt.exe with -debug=1, didn't get [lock]'s
5)Tried to add DEBUG_LOCKORDER parameter, but with it the build failed (bug?).
If I can't build the solution, I will try to reproduce t
...

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817788182)
> Can you post the full log?

See https://github.com/hebasto/artefacts/blob/arm-OOM-logs/arm-OOM-logs/debug.log-04fb0b35cf18

👍 vasild approved a pull request: "test: fix `AddNode` unit test failure on OpenBSD"
(https://github.com/bitcoin/bitcoin/pull/28891#pullrequestreview-1738598461)
ACK 007d6f0e85bc329040bb405ef6016339518caa66

⚠️ maflcko reopened an issue: "Sync slow"
(https://github.com/bitcoin/bitcoin/issues/26063)
Syncing blockchain is sometimes very slow. I think this has become more common in the past months.

Here's a screenshot from Network Traffic window in the GUI, see how there are long periods of absolutely no traffic. Also see how it only downloaded about 100 MB during the first 30minutes of syncing. It's also often connected to just 1 or 2 peers which is weird.

![bitcointrafficverylowandslow](https://user-images.githubusercontent.com/79941375/189544394-3cb3dd32-b384-437e-a785-456b149b0258.p
...

💬 maflcko commented on pull request "bench: add readblock benchmark":
(https://github.com/bitcoin/bitcoin/pull/26684#discussion_r1398383803)
```suggestion
DataStream stream{benchmark::data::block413567};
```

(see compile failure)

💬 maflcko commented on pull request "depends: bump libmultiprocess to fix capnproto deprecation warnings":
(https://github.com/bitcoin/bitcoin/pull/28907#issuecomment-1817829246)
lgtm ACK 21bfee0720ba72935d4f9fc4c2a2887ae5b54092

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817833689)
Thanks a lot for the log! I am now pretty certain that the allocated blocks from the pool are not counted in `DynamicUsage`. I can reproduce practically exactly same cache sizes as in the log when I set `usage_chunks=0` here (and run 32bit bitcoind on x86): https://github.com/bitcoin/bitcoin/blob/master/src/memusage.h#L201
So the `bucket_count` is calculated correctly which can be seen by the memory jumps.

So either `pool_resource->ChunkSizeBytes()` or `pool_resource->NumAllocatedChunks()`
...

💬 sipa commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817834734)
@martinus Is it possible that due to a mistake in the guessed node size, the utxo cache entries are allocated through the fallback to the normal allocator?