💬 maflcko commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3560406701)
If `--preset=libfuzzer-nosan` is the only thing that works reliably, then only that should be mentioned. And possibly mention the option to reproduce existing fuzz inputs with a sanitizer, without libfuzzer.

💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547912404)
Thanks! Dropped.

💬 Crypt-iQ commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2547912908)
It could also be done with standard txns: if there are 25 txn's each 320KWU, it's also not possible to split.

I guess I'm wondering how this protocol should handle not being able to split an 8MWU template into two chunks? It could split it into three or give up if these witness-heavy cases are pathological.

✅ maflcko closed an issue: "test: spurious failure in p2p_leak_tx.py --v1transport"
(https://github.com/bitcoin/bitcoin/issues/33090)

💬 maflcko commented on issue "test: spurious failure in p2p_leak_tx.py --v1transport":
(https://github.com/bitcoin/bitcoin/issues/33090#issuecomment-3560422313)
closing for now. a new issue can be opened, the next time this happens again.

💬 maflcko commented on pull request "ci: Enable experimental kernel stuff in most CI tasks via `dev-mode`":
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2547946443)
This lead to a failure: https://github.com/maflcko/bitcoin-core-nightly/actions/runs/19550555322/job/55988016546#step:12:25:

```

stdout:
2025-11-20T22:23:58.576632Z TestFramework (INFO): PRNG seed is: 4045980459550867813
2025-11-20T22:23:58.577475Z TestFramework (INFO): Initializing test directory /Users/runner/work/_temp/test_runner_₿_🏃_20251120_220520/tool_bitcoin_chainstate_201
2025-11-20T22:23:59.071213Z TestFramework (INFO): Testing bitcoin-chainstate ['/Users/runner/work/bitcoin-core-ni
...

💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#issuecomment-3560480250)
> If we are migrating, should we just do this at this same time as we actually migrate, then we don't have to worry about both. Are we dropping support for the old runtime at the same time we switch to using the new ones in releases?

Yes, we are going to migrate the Windows release binaries to UCRT.

However, the depends build subsystem has capabilities to build for a wider range of targets than those used in releases. This is well documented in README.md, which refers, for example, to `i68
...

💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547970130)
Given that full UCRT-capable toolchains are not yet available across all major distributions, developers on Ubuntu, for example, may still want to build for `x86_64-w64-mingw32`.

💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060905)
Done

💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060973)
Added some comments, please check them out

💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061021)
Added something like this, thanks

💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061081)
Did something similar in a new commit, what do you think?

💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061274)
Added the explanation to the commit message as well

📝 fjahr opened a pull request: "Export embedded ASMap RPC"
(https://github.com/bitcoin/bitcoin/pull/33920)
This depends on the embedded data PR itself (#28792), until merge this will remain in draft status. All commit but the last one are from there.

There has been interest in exporting the embedded data back into a file. This is implemented here with a simple `exportasmap` RPC which provides this functionality. The exported file can be used to verify the data integrity or statistical analysis using e.g. `contrib/asmap-tool.py`.

🤔 w0xlt reviewed a pull request: "argsman, cli: GNU-style command-line option parsing (allows options after non-option arguments)"
(https://github.com/bitcoin/bitcoin/pull/33540#pullrequestreview-3490620415)
Restructuring `ProcessOptionKey` as below seems to solve the problem of `./build/bin/bitcoin-cli --datadir=/tmp/btc1 --signet getblockhash 1000`.

```cpp
bool ArgsManager::ProcessOptionKey(std::string& key, std::optional<std::string>& val, std::string& error, const bool found_after_non_option) {
bool double_dash{false};
const std::optional<std::string> original_val{val};
std::string original_input{key};
if (val) original_input += "=" + *val;

// Normalize leading das
...

💬 glozow commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3560795513)
ACK 3fb3c230c93

💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519792868)
I think these functions should actually require the lock to already be held. They are only called from `MemPoolAccept` so this is always true.

💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519723491)
cec26203732ce3883e7e014f954ccd73c3c0099d: The function signature in chain.h still calls this `descendants`

💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519646193)
Now that the feerate diagram outputs weight, the sanity check can be stronger:

```diff
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index 472ed581145..0be261ad964 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -418,6 +418,8 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei

uint64_t checkTotal = 0;
CAmount check_total_fee{0};
+ CAmount check_total_modified_fee{0};
+ int32_t check_total_adjusted_weight{0};
uint
...

💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519846231)
Is this supposed to be the name of the param?

```suggestion
uint256 hash = ParseHashV(request.params[0], "txid");
```