💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420254312)
I find it confusing to have one condition to set the flag to `true` and a different condition to set it to `false`. I mean this:

```cpp
if (A) flag = true;
if (B) flag = false;
```
because, for example, it may happen that `B` is `true` and the flag is `true` (if the first `if` was not executed yet).

In this case it can be simpler:
```cpp
if (C) flag = true;
if (!C) flag = false;
// or just:
flag = C;
```
and C should be just "our highest block is older than 48h" (regardless of w
...

💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420242098)
Seems like `!fInitialDownload && ` can be removed? If `IsBlockCloseToTip()` is `true` then that block is 3h20min or younger. In this case `fInitialDownload` will always be `false` because it uses 24h, right?

💬 fanquake commented on pull request "fuzz: p2p: Detect peer deadlocks":
(https://github.com/bitcoin/bitcoin/pull/29009#issuecomment-1846978003)
cc also @mzumsande @sipa

👍 fanquake approved a pull request: "build: Require C++20 compiler"
(https://github.com/bitcoin/bitcoin/pull/28349#pullrequestreview-1772145687)
ACK fa6e50d6c79633e22ad4cfc75f56aaa40112ecbb

🚀 fanquake merged a pull request: "wallet: batch all individual spkms setup db writes in a single db txn"
(https://github.com/bitcoin/bitcoin/pull/28894)

🚀 fanquake merged a pull request: "test: Extends MEMPOOL msg functional test"
(https://github.com/bitcoin/bitcoin/pull/28485)

🚀 fanquake merged a pull request: "test: fix v2 transport intermittent test failure (#29002)"
(https://github.com/bitcoin/bitcoin/pull/29006)

✅ fanquake closed an issue: "Intermittent test failure in p2p_v2_transport"
(https://github.com/bitcoin/bitcoin/issues/29002)

✅ fanquake closed a pull request: "fuzz: p2p: Detect peer deadlocks"
(https://github.com/bitcoin/bitcoin/pull/29009)

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420319394)
Hm, as far as I know there's no easy way... I once found a bug like that where a deterministic random generator was used, and the unit test was asserting the exact output of an algorithm given a fixed but random input. On Windows the result was different because there the compiler had chosen a different evaluation order.

💬 ismaelsadeeq commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420321030)
Updated, thanks

💬 ismaelsadeeq commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420321687)
Fixed in https://github.com/bitcoin/bitcoin/commit/fab46cc454f94b33dda6bc68a7234b439310f358 thank you @martinus

💬 fanquake commented on pull request "build: switch to using LLVM 17.x for macOS builds":
(https://github.com/bitcoin/bitcoin/pull/28880#issuecomment-1847041044)
> Did you have steps to reproduce outside of guix?

Not yet. Will get some, and open an issue upstream.

💬 maflcko commented on issue "fuzz: Left over tmp files when fuzzing with afl++":
(https://github.com/bitcoin/bitcoin/issues/28811#issuecomment-1847041403)
Not sure what to do here. There are some options:

* Forcing a static directory path per fuzzing task (Identified by target name + the CPU it runs on, or the "worker ID"), which will be cleared before the fuzz process starts.
* Detecting a low storage and then aborting the fuzzing campaign with a verbose error message, educating about the timeout?
* (something else?)

I think an early abort makes the most sense, because with frequent timeouts, it doesn't make sense to continue the fuzzing
...

📝 maflcko reopened a pull request: "fuzz: p2p: Detect peer deadlocks"
(https://github.com/bitcoin/bitcoin/pull/29009)
It may be possible that a peer connection will deadlock, due to software bugs such as https://github.com/bitcoin/bitcoin/pull/18808.

Fix this by detecting them in the fuzz target.

Can be tested by introducing a bug such as:

```diff
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 1067341495..97495a13df 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -2436,3 +2436,3 @@ void PeerManagerImpl::ProcessGetData(CNode& pfrom, Peer& peer, const std::ato
...

💬 fanquake commented on pull request "test: fix v2 transport intermittent test failure (#29002)":
(https://github.com/bitcoin/bitcoin/pull/29006#issuecomment-1847045128)
Note there was a typo in the commit message. This fixed #29002, not #29009 (which accidently got closed).

⚠️ maflcko opened an issue: "test: Add TestNode wait_until helper"
(https://github.com/bitcoin/bitcoin/issues/29029)
### Motivation

Currently, inside TestNode, the global `wait_until_helper_internal` must be used, and each time the timeout factor must be passed.

See https://github.com/bitcoin/bitcoin/pull/29006#discussion_r1416891272

### Possible solution

It would be nice to have a method `wait_until` that wraps the `wait_until_helper_internal` call, like in other places.

### Useful Skills

* Compiling Bitcoin Core from source
* Running the C++ unit tests and the Python functional tests
* Python 3

##
...

💬 maflcko commented on pull request "test: fix v2 transport intermittent test failure (#29002)":
(https://github.com/bitcoin/bitcoin/pull/29006#discussion_r1420334764)
Alternatively, it would be good to pass the `timeout` option to `assert_debug_log`, so that it is well-documented that the debug log is used to sync.

💬 martinus commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#issuecomment-1847059669)
code review ACK fab46cc

💬 petertodd commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1847064561)
Worth noting that the vast majority of inscriptions are tiny, BRC-20 tokens, with ~50 bytes of data: https://ordiscan.com/inscriptions

The data in this use-case isn't actually significant. Typically ~50WU out of a ~600WU transaction. Even if BRC-20 and similar tokens modify the protocol to not actually put any data in the Bitcoin chain, they *still* would drive fees up significantly due to the transactions themselves.