📝 ismaelsadeeq opened a pull request: "doc: clarify the documentation of `Assume` assertion"
(https://github.com/bitcoin/bitcoin/pull/32100)
Statements inside `Assume` may be optimized away in production builds when the compiler proves they are side-effect-free.
This makes `Assume` useful for testing invariants that are always evaluated in debug builds, allowing violations to be caught during fuzzing with the hope that it wont incur runtime cost in release builds.
This use case is demonstrated in #31363 and is suggested to be documented in https://github.com/bitcoin/bitcoin/pull/31363#issuecomment-2736410023.

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#issuecomment-2740049673)
> That makes sense. Might be a good idea to update doc/developer-notes.md pointing out that use case? It currently says:

Done in #32100

💬 l0rinc commented on pull request "[IBD] specialize block serialization":
(https://github.com/bitcoin/bitcoin/pull/31868#discussion_r2005441297)
Now that #31519 was merged, I've rebased an moved it out of draft.

👋 l0rinc's pull request is ready for review: "[IBD] specialize block serialization"
(https://github.com/bitcoin/bitcoin/pull/31868)

💬 willcl-ark commented on issue "ci: failure in interface_usdt_utxocache.py":
(https://github.com/bitcoin/bitcoin/issues/31951#issuecomment-2740183900)
From reading up on this a little it seems to be possible that if the tracepoint:

- includes runtime [lookups](https://github.com/bitcoin/bitcoin/blob/aa87e0b44600a32b32a4b123d4f90d097f1f106f/src/txmempool.cpp#L513-L518)
- is executed in a multi-threaded (or multi-CPU) environment
- (possibly other factors)

...then it may not be possible to totally guarantee ordering at userspace collection points. One can use BPF [queues](https://docs.kernel.org/bpf/map_queue_stack.html), but I suspect this wo
...

🤔 ismaelsadeeq reviewed a pull request: "Have createNewBlock() wait for tip, make rpc handle shutdown during long poll and wait methods"
(https://github.com/bitcoin/bitcoin/pull/31785#pullrequestreview-2702397335)
Concept ACK

In 64a2795fd4fe223a55564c31e9fa36264e79ac22 "rpc: handle shutdown during long poll and wait methods"

is a use for returning the last known tip?

If not, should we simplify the behavior by always returning nullopt when the tip has not changed or no better block is available?

Or It will be more consistent to to return the last known tip if it is set, when this edge case happen handle it by returning nullopt.

✅ vasild closed a pull request: "i2p: make a time gap between creating transient sessions and using them"
(https://github.com/bitcoin/bitcoin/pull/32065)

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005472525)
A new comment has been posted to that bug report.

💬 0xB10C commented on issue "ci: failure in interface_usdt_utxocache.py":
(https://github.com/bitcoin/bitcoin/issues/31951#issuecomment-2740221745)
> To change only this test is relatviely simple: https://github.com/bitcoin/bitcoin/compare/master...willcl-ark:bitcoin:usdt-order-independant but it will be more work to apply to all the tests...

This was the first, and for now, the only time we saw this test fail due to ordering problems. I think we can't completely rule out ordering problems, but IMO it would be good to see this happening in some other test(s) before we start changing them.

💬 ismaelsadeeq commented on pull request "mining: drop unused -nFees and sigops from CBlockTemplate":
(https://github.com/bitcoin/bitcoin/pull/31897#issuecomment-2740221944)
re-ACK 226d81f8b708ea1c3a39ec58446e291fe7440fdd

Latest change added functional test coverage for the `sigops` and `fee` field of txs returned from `getblocktemplate` RPC

💬 vasild commented on pull request "i2p: make a time gap between creating transient sessions and using them":
(https://github.com/bitcoin/bitcoin/pull/32065#issuecomment-2740226777)
`a22a3b3c4c...48a636cdde`: rebase due to conflicts and reduce the pre-created sessions to 1, given the above. Some logs from running this:

```
974be1f338 startup +129s: made new session
974be1f338 startup +290s, 161s after creation: connect failed
974be1f338 startup +372s, 243s after creation: connect failed
974be1f338 startup +678s, 549s after creation: connect ok, connection duration: 1305s, destroyed after that

55723ba1fc startup +1385s: made new session
55723ba1fc startup +1441s,
...

📝 vasild reopened a pull request: "i2p: make a time gap between creating transient sessions and using them"
(https://github.com/bitcoin/bitcoin/pull/32065)
Connecting to an I2P peer consists of creating a session (the
`SESSION CREATE` command) and then connecting to the peer using that
session (`STREAM CONNECT ID=session_id ...`).

This change is only relevant for transient sessions because when a
persistent session is used it is created once and used for all
connections.

Before this change Bitcoin Core would create the session and use it in
quick succession. That is, the `SESSION CREATE` command would be
immediately followed by `STREAM
...

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005488831)
The issue can be observed in the following scenario on an `aarch64` machine:
```
$ env HOSTS=x86_64-linux-gnu ./contrib/guix/guix-build
...
Building qt...
ninja: error: 'qtbase/src/platformsupport/input/CMakeFiles/InputSupportPrivate.dir/cmake_pch.hxx.gch', needed by 'qtbase/src/platformsupport/input/CMakeFiles/InputSupportPrivate.dir/InputSupportPrivate_autogen/mocs_compilation.cpp.o', missing and no known rule to make it
make: *** [funcs.mk:303: /bitcoin/depends/work/build/x86_64-linux-
...

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2740271781)
Some of @fanquake's recent feedback has been addressed.

Additionally, the behaviour when cross-compiling for `HOST=x86_64-w64-mingw32` on a system with a native Vulkan package installed has been fixed. Qt 6 erroneously (a bug?) labels Vulkan as available for cross-compiling. Vulkan has been disabled for `mingw32`, which effectively makes it disabled for all platforms.

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005514004)
Thanks! [Fixed](https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2740271781).

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005514457)
Thanks! [Fixed](https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2740271781).

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005514872)
Thanks! [Reworked](https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2740271781).

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2005525735)
Otherwise, it fails to find XCB:
```
$ make -C depends -j 16 qt
...
CMake Error at qtbase/cmake/QtBuildInformation.cmake:522 (message):
Feature "xcb": Forcing to "ON" breaks its condition:

QT_FEATURE_thread AND TARGET XCB::XCB AND TEST_xcb_syslibs AND QT_FEATURE_xkbcommon_x11

Condition values dump:

QT_FEATURE_thread = "ON"
TARGET XCB::XCB found
TEST_xcb_syslibs = "1"
QT_FEATURE_xkbcommon_x11 = "OFF"

Call Stack (most recent call first):
qtb
...

💬 Eunovo commented on pull request "[EXPERIMENTAL] Schnorr batch verification for blocks":
(https://github.com/bitcoin/bitcoin/pull/29491#discussion_r2005563093)
https://github.com/bitcoin/bitcoin/pull/29491/commits/6055f3a6f530818e2805d11debb1fb2ce81fc5c0: This leaves the master thread to do all the "Pubkey recovery"(I think that's what its called?) work in each `batch.Add` call, which is substantial. We can call "secp256k1_xonly_pubkey_parse" when collecting the signatures so the master thread is not stuck doing all the work to parse the XOnlyPubkey.

📝 willcl-ark opened a pull request: "Accept unordered tracepoints in interface_usdt_utxocache.py"
(https://github.com/bitcoin/bitcoin/pull/32101)
We have encountered an instance where the tracepoints were not collected in the same order they were fired (#31951).

Tracepoint ordering is not guaranteed in userspace for a number of reasons.

As this test does not require a strict collection/processing order collect `expected` and `actual` events into dicts and compare them.

This will gracefully handle both the number of events, and out-of-order events should they reoccur in the future.

Fixes: #31951