💬 sr-gi commented on pull request "test: deduplicates p2p_tx_download constants":
(https://github.com/bitcoin/bitcoin/pull/31758#issuecomment-2625102131)
@tdb3 I de-duplicated even more, plus renamed some of the remaining ones to match the actual names in `txdownloadman.h` (and updated the comment referring to `net_processing`, given the constants do not live there anymore).

As mentioned in-line, notice how `INBOUND_PEER_TX_DELAY` and `NONPREF_PEER_TX_DELAY` refer to the same concept. The latter was introduced in #20171 instead of remaining (or re-using) the former.

💬 l0rinc commented on pull request "Use number of dirty cache entries in flush warnings/logs":
(https://github.com/bitcoin/bitcoin/pull/31703#discussion_r1935992350)
> I don't understand why you're looking at snapshot size

> not a good measure of data written

> and not use snapshot size as a proxy

I understand that the dirty entries in the snapshot are not a perfect representation (except for the AssumeUTXO tests I was doing, which likely skewed my recommendations), but I though it's what we're already doing here when we're calculating "approx_disk_usage" from "coins_dirty_count".

> None of that seems a good fit for this PR, though

I agree, if
...

💬 l0rinc commented on pull request "Use number of dirty cache entries in flush warnings/logs":
(https://github.com/bitcoin/bitcoin/pull/31703#discussion_r1935997972)
Sure, though this won't warn us if it actually becomes unused.

💬 l0rinc commented on pull request "Use number of dirty cache entries in flush warnings/logs":
(https://github.com/bitcoin/bitcoin/pull/31703#discussion_r1935999555)
Alternatively, we could collect a few hundred stale blocks (found 45 raw blocks so far via https://github.com/bitcoin-data/stale-blocks) and create a stale-block-proxy node for testing reorgs with real data:
* A freshly built test node would connect only to this proxy, which would simulate the original chain forks.
* It serves headers & blocks exactly as they were originally seen (without storing them, requesting non-stale ones from the network).
* The proxy pretends a stale block is the tip,
...

💬 victorvianna commented on pull request "[WIP] leveldb: pull upstream C++23 changes":
(https://github.com/bitcoin/bitcoin/pull/31766#issuecomment-2625180290)
FYI the upstream PR landed

💬 yancyribbens commented on pull request "test: Add expected result assertions":
(https://github.com/bitcoin/bitcoin/pull/31656#issuecomment-2625214697)
@theuni maybe you could review this? In short, the test does not test what it purports to without also asserting the expected result.

💬 ryanofsky commented on pull request "ci: build multiprocess on most jobs":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2625235833)
> The macOS 14 native no depends job fails with [chaincodelabs/libmultiprocess#138](https://github.com/chaincodelabs/libmultiprocess/issues/138).

Seems to be passing now so I guess the attempted fix in f3f4685bc4f8d42c6ef6dbd223de25da235155ee is working. Will go ahead and merge that and add it to the base PR.

I also have a fix for the 403 download / "Checksum missing or mismatched for native_libmultiprocess" errors.

<details><summary>diff</summary>
<p>

```diff
--- a/depends/funcs.m
...

💬 mzumsande commented on pull request "multi-peer orphan resolution followups":
(https://github.com/bitcoin/bitcoin/pull/31666#discussion_r1936089704)
> Hm. What do you mean by "the actual full validation will only be done once" btw?

I meant that aborting due to missing inputs should be fast compared to full validation (signature checks), which will only be done once, because after the tx is in the mempool all subsequent checks from other peer's worksets will abort quickly.

💬 Sjors commented on pull request "ci: build multiprocess on most jobs":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2625260660)
> also have a fix for the 403 download

Let's see how that goes.

💬 sipa commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#discussion_r1936122569)
In commit "build: Include all MacOS binaries for codesigning"

What is the effect of moving this code down? Will it pick up more artifacts that have been produced in between?

💬 glozow commented on pull request "multi-peer orphan resolution followups":
(https://github.com/bitcoin/bitcoin/pull/31666#discussion_r1936129171)
> I meant that aborting due to missing inputs should be fast compared to full validation (signature checks), which will only be done once,

Ah ok same page 👍 was wondering if you were thinking of some other kind of caching

📝 brunoerg opened a pull request: "test: check `scanning` field from `getwalletinfo`"
(https://github.com/bitcoin/bitcoin/pull/31768)
During a rescan, check that `getwalletinfo` returns properly information (the scanning field) about it.

💬 achow101 commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#discussion_r1936154607)
Yes, this makes it include the directory containing the binaries in the codesigning tarball.

📝 brunoerg converted_to_draft a pull request: "test: check `scanning` field from `getwalletinfo`"
(https://github.com/bitcoin/bitcoin/pull/31768)
During a rescan, check that `getwalletinfo` returns properly information (the scanning field) about it.

💬 tnndbtc commented on pull request "miniscript: fixes #29098 by only use first k valid signatures":
(https://github.com/bitcoin/bitcoin/pull/31719#discussion_r1936224461)
This was caught by running ci fuzz test in docker container:
# cd /ci_container_base/ci/scratch/build-aarch64-unknown-linux-gnu/test/fuzz
# ./test_runner.py -j8 -l DEBUG /ci_container_base/ci/scratch/qa-assets/fuzz_corpora/ miniscript_smart --empty_min_time=60

💬 VzxPLnHqr commented on pull request "Prevent file descriptor exhaustion from too many RPC calls":
(https://github.com/bitcoin/bitcoin/pull/27731#issuecomment-2625486456)
I am not familiar with the intricacies of this PR, but is it possible for bitcoind to detect this impending crash before it happens and just return some sort of 500 error?

I ran into this issue (using v28.0) when running a straightforward script which was calling `getblock` for each block, starting from genesis. After a couple thousand blocks bitcoind crashed with the file descriptor error.

After some trial and error I have found that putting a 100 millisecond delay between http requests
...

💬 ismaelsadeeq commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1936237852)
In "Add waitNext() to BlockTemplate interface" a61fb2fd2d6b338c08c619e4605521a41bd3edd9

I think we are not just creating a block template after ticks but on each iteration of this loop, which continues infinitely in the default case. Since we are holding `cs_main` continuously, wouldn't this cause resource contention and delay other components of the node?

My concern is that, regardless of whether the mempool improves, we keep creating block templates.

Currently there is no reliable wa
...

💬 ismaelsadeeq commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1936212347)
In "Add waitNext() to BlockTemplate interface" a61fb2fd2d6b338c08c619e4605521a41bd3edd9

We already have the comments about the default in node types `BlockWaitOptions` docstring, writing it here is duplicating same information, when we update the default we have to update both places.

I think it will be better to just move the fee threshold description comment to node types `BlockWaitOptions` docstring and delete the duplicate here.

💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1936242611)
I tried to make it a quick TL&DR so someone can understand the most important behaviour, without having to go and read the entire struct doc (which might grow, and not all code let you hover and see the full thing in a popup).

💬 ryanofsky commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1936248702)
re: https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1936237852

> In "Add waitNext() to BlockTemplate interface" [a61fb2f](https://github.com/bitcoin/bitcoin/commit/a61fb2fd2d6b338c08c619e4605521a41bd3edd9)
>
> I think we are not just creating a block template after ticks but on each iteration of this loop, which continues infinitely in the default case. Since we are holding `cs_main` continuously, wouldn't this cause resource contention and delay other components of the node?


...