💬 willcl-ark commented on issue "Crash upon RPC v1 connection in v28.0.0":
(https://github.com/bitcoin/bitcoin/issues/31041#issuecomment-2508119954)
Oh yes, it could do. I had interpreted OP to mean bitcoin core had 4GB (or 8GB) of RAM to itself, but if both of those were trying to share that amount, it seems like it might not work. I note that over in #31039 it was reported that:

> The machine I use has 4GB and there is nothing other than Bitcoin Core on it.

I got suspicious of my own earlier results as I've seen bitcoin core using more memory than this previously, so re-ran an electrs sync to block 600,000 only this time. `bitcoind`
...

💬 Sjors commented on pull request "Drop script_pub_key arg from createNewBlock":
(https://github.com/bitcoin/bitcoin/pull/31318#issuecomment-2508149376)
This PR incidentally "fixes" the IPC bug discovered in https://github.com/bitcoin/bitcoin/pull/31318.

📝 hebasto opened a pull request: "[POC] cmake: Introduce LLVM's Source-based Code Coverage reports"
(https://github.com/bitcoin/bitcoin/pull/31394)
The `gcov`-based code coverage does not work with Clang (please refer to https://github.com/bitcoin/bitcoin/issues/31047 for more details).

This PR employs the LLVM's [Source-based Code Coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html).

Here are some examples of usage:
```
cmake -B build -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DBUILD_FOR_COVERAGE=ON
cmake --build build --target total_coverage
firefox build/test_bitcoin.coverage/index.html
```
or
```
...

💬 Sjors commented on pull request "multiprocess: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2508176320)
In light of https://github.com/Sjors/bitcoin/issues/71#issuecomment-2508157740 I think `bitcoin-mine` should call _all_ interface methods. But this can wait for a followup, maybe by myself.

✅ arik-so closed a pull request: "Disable RBF Rule 2"
(https://github.com/bitcoin/bitcoin/pull/30964)

💬 arik-so commented on pull request "Disable RBF Rule 2":
(https://github.com/bitcoin/bitcoin/pull/30964#issuecomment-2508493608)
Thank you so much for your plentiful and insightful responses! I will close this PR and am very much looking forward to cluster mempool obviating it entirely.

👍 BrandonOdiwuor approved a pull request: "cmake, qt: Use absolute paths for includes in MOC-generated files"
(https://github.com/bitcoin/bitcoin/pull/31361#pullrequestreview-2470476711)
ACK 6f4128e3a838d03f46d397c15bc5333287e14863

💬 hodlinator commented on pull request "test: cover base32/base58/base64 with symmetric roundtrip fuzz (and padding) tests":
(https://github.com/bitcoin/bitcoin/pull/30746#discussion_r1863916545)
Great that you made time to look into this!

> An alternative could be to forbid the direct use of the depleting member functions (with a linter) and add a new helper which eats a `FuzzedDataProvider&&` and returns the bytes in it. This way, the existing use-after-move checks can be used.

So you mean disallowing direct calls to `ConsumeRemainingBytes*`-family of methods only, and provide a helper that does only that part instead after swallowing up `FuzzedDataProvider&&` so it should no lon
...

👍 tdb3 approved a pull request: "cmake: Improve build script correctness"
(https://github.com/bitcoin/bitcoin/pull/31357#pullrequestreview-2470663952)
light test ACK ab5c63edccea7957e2c7b3b9d8b04655a7f82f22

On master (dbc8ba12f3b3548dd6955293c5d650320ca39c5b):

Native (Make)
```
$ cmake -B build -DBUILD_DAEMON=OFF -DBUILD_CLI=OFF -DBUILD_TX=OFF -DBUILD_UTIL=OFF -DENABLE_WALLET=OFF -DBUILD_TESTS=OFF
...
-- Configuring done
CMake Error at src/CMakeLists.txt:289 (target_link_libraries):
Target "bitcoin_node" links to:

libevent::core

but the target was not found. Possible reasons include:

* There is a typo in the t
...

💬 willcl-ark commented on issue "Crash upon RPC v1 connection in v28.0.0":
(https://github.com/bitcoin/bitcoin/issues/31041#issuecomment-2508890978)
> We also don't have any confirmation that this same issue was not present on 27.x. I will try and test this later to see if there is any difference to block 600k again.

By block 400,000 bitcoin core v27.0 peak usage hit `VmPeak: 5048020 kB`, which is approx the same (marginally higher than v28.0) at this stage where it too roughly levels out.

I'm not going to run this further than the block 550k I am up to now, as these results seem so similar. My read is that:

- Electrs takes 50% mor
...

💬 i-am-yuvi commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2508897599)
> > We already keep stats for each and every peer, displayed in the `getpeerinfo` RPC, e.g. `bitcoin-cli getpeerinfo`.
>
> do those stats include CPU time though?

We don't keep CPU time of each peer, you can see here
https://developer.bitcoin.org/reference/rpc/getpeerinfo.html?highlight=peerinfo

📝 TheCharlatan opened a pull request: "build: Set shared linker flags in toolchain file"
(https://github.com/bitcoin/bitcoin/pull/31395)
These are required when cross-compiling shared libraries such as the kernel library.

This was discovered after attempting to cross-compile the kernel library and running into the following error:
```
[100%] Linking CXX shared library libbitcoinkernel.dylib
/usr/bin/ld: unrecognised emulation mode: llvm
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386pep i386pe
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [src/kernel
...

💬 darosior commented on pull request "Miner: never create a template which exploits the timewarp bug":
(https://github.com/bitcoin/bitcoin/pull/31376#issuecomment-2509078020)
Why? As mentioned in OP it would only delay such a soft fork if there is a concern that miners could produce an invalid block template, and we can choose our software to not support a timewarp attack without considering whether it might be fixed at the consensus level at all.

> I'd rather not have to think about different Bitcoin Core versions having a different value for MAX_TIMEWARP.

I don't understand. `MAX_TIMEWARP` would never come into play in any normal circumstance. What is your co
...

💬 1440000bytes commented on issue "Add wallet RPC to get new taproot address from a silent payment address":
(https://github.com/bitcoin/bitcoin/issues/31258#issuecomment-2509080079)
This library can be used to get a p2tr address from a silent payment address: https://github.com/Bitshala-Incubator/silent-pay

📝 tdb3 opened a pull request: "test: simple ordering optimization to reduce runtime"
(https://github.com/bitcoin/bitcoin/pull/31396)
Noticed in #31371 that the position of `mempool_ephemeral_dust` within `BASE_SCRIPTS` was lengthening total test runtime. Instead of moving only that test, looked for others to move to reduce runtime.

This is a quick optimization that was found to reduce overall functional test runtime of up to around 20% (depending on jobs and machine characteristics). Since it seems like test ordering could be done in many different ways, with many variables, and bike shedding could creep in, a relatively s
...

💬 tdb3 commented on pull request "test: simple ordering optimization to reduce runtime":
(https://github.com/bitcoin/bitcoin/pull/31396#issuecomment-2509084875)
### Approach taken
The position of most tests (with bdb, excluding extended tests) in `BASE_SCRIPTS` was compared to the observed runtime of the test (using a low job count, to avoid saturation/contention). The difference in position was calculated (called deviation). Sorted by deviation. Filtered out all results with runtimes 20 seconds and under. Filtered for results beyond the first 100 positions in `BASE_SCRIPTS`. This left 5 tests. Moved those 5 tests nearer to the front of `BASE_SCRIPTS`
...

💬 tdb3 commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#discussion_r1864403975)
included, thanks

💬 tdb3 commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2509113519)
> Any reason not to scope the new variables? [luke-jr@851d354](https://github.com/luke-jr/bitcoin/commit/851d354fc4f94695aabd12d21e470dc90d267b93)

moved, thanks

💬 tdb3 commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2509114510)
Updated with suggested changes

💬 maciejsszmigiero commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2509167957)
Updated the new max file size value to 32 MiB, as suggested.