👍 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.

💬 l0rinc 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#discussion_r1864455083)
Thanks, please resolve the comment

💬 l0rinc 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-2509168574)
ACK b73d3319377a4c9d7e2dd279c3d106002585bc36

👍 andrewtoth approved a 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#pullrequestreview-2471058147)
ACK b73d3319377a4c9d7e2dd279c3d106002585bc36

👍 TheCharlatan approved a 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#pullrequestreview-2471068260)
ACK b73d3319377a4c9d7e2dd279c3d106002585bc36

💬 sipa 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-2509202949)
Concept ACK. Please update the PR title and description to reflect the new size.

👍 willcl-ark approved a pull request: "dbwrapper: Bump LevelDB max file size to 32 MiB to avoid system slowdown from high disk cache flush rate"
(https://github.com/bitcoin/bitcoin/pull/30039#pullrequestreview-2471071161)
ACK b73d3319377a4c9d7e2dd279c3d106002585bc36

👍 tdb3 approved a pull request: "dbwrapper: Bump LevelDB max file size to 32 MiB to avoid system slowdown from high disk cache flush rate"
(https://github.com/bitcoin/bitcoin/pull/30039#pullrequestreview-2471071557)
ACK b73d3319377a4c9d7e2dd279c3d106002585bc36

📝 glozow opened a pull request: "p2p: track and use all potential peers for orphan resolution"
(https://github.com/bitcoin/bitcoin/pull/31397)
Part of #27463.

(Transaction) **orphan resolution** is a process that kicks off when we are missing UTXOs to validate an unconfirmed transaction. We currently request missing parents by txid; BIP 331 also defines a way to [explicitly request ancestors](https://github.com/bitcoin/bips/blob/master/bip-0331.mediawiki#handle-orphans-better).

Currently, when we find that a transaction is an orphan, we only try to resolve it with the peer who provided the `tx`. If this doesn't work out (e.g. the
...