💬 brunoerg commented on pull request "fuzz: fix bad alloc in connman target":
(https://github.com/bitcoin/bitcoin/pull/31235#issuecomment-2462141985)
Force-pushed addressing https://github.com/bitcoin/bitcoin/pull/31235#discussion_r1832608263

👍 vasild approved a pull request: "fuzz: fix bad alloc in connman target"
(https://github.com/bitcoin/bitcoin/pull/31235#pullrequestreview-2420899097)
ACK 9cdf4e67bf04b5abb46b4ce1cf4c306819afe056

📝 vasild opened a pull request: "test: clarify log messages when handling SOCKS5 proxy connections"
(https://github.com/bitcoin/bitcoin/pull/31239)
Clarify log messages when handling SOCKS5 proxy connections.

Suggested in https://github.com/bitcoin/bitcoin/pull/29420#discussion_r1815521913

💬 vasild commented on pull request "test: extend the SOCKS5 Python proxy to actually connect to a destination":
(https://github.com/bitcoin/bitcoin/pull/29420#discussion_r1832675558)
Done in https://github.com/bitcoin/bitcoin/pull/31239

💬 josibake commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#issuecomment-2462248717)
Regarding the @DrahtBot comment, I am still working on this PR and will be rebasing this week, once I've finished responding to review feedback in https://github.com/bitcoin-core/secp256k1/pull/1519

💬 bigspider commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#issuecomment-2462257471)
Looking good!

I can confirm that I was able to complete two e2e tests on regtest (commit 09a6091711eef299de7cfbfd340a112706422c81), using Ledger's MuSig2 implementation for a cosigner and bitcoin-core for the other one.

The descriptors had the form:

```tr(musig(ledger_key, bitcoin_core_key)/<0;1>/*)```

and:

```tr(nums_key/<0;1>/*, musig(ledger_key, bitcoin_core_key)/<0;1>/*)```

In both cases, the Ledger device was just the MuSig2 cosigner, while bitcoin-core was both the other
...

📝 edilmedeiros opened a pull request: "RFC: doc: Fix dead links to mailing list archives"
(https://github.com/bitcoin/bitcoin/pull/31240)
Unfortunately, lists.linuxfoundation.org is no longer hosting any mailing list archives, not just for bitcoin-dev but all the other mailing lists too.

I'm opening this to discuss how to best approach the fix.

@kanzure suggested in https://github.com/bitcoin/bitcoin/pull/29782#issuecomment-2460974096:

> Wait and see if they put it back up.
>
> Update those locations in the source code to the proposed new urls like https://gnusha.org/pi/bitcoindev/c3f68b73-84c6-7428-4bf6-b47802141392@
...

💬 edilmedeiros commented on pull request "doc: Update the developer mailing list address.":
(https://github.com/bitcoin/bitcoin/pull/29782#issuecomment-2462353678)
Opened #31240 so that we can discuss the best approach to fix this.
I'll check if there are other broken links around.

✅ kevkevinpal closed a pull request: "[tests] New fuzz target wallet_rpc"
(https://github.com/bitcoin/bitcoin/pull/30570)

💬 kevkevinpal commented on pull request "[tests] New fuzz target wallet_rpc":
(https://github.com/bitcoin/bitcoin/pull/30570#issuecomment-2462369297)
> Are you still working on it?

Sorry I've been quite busy, I can close this PR and leave it up for grabs since I havent had a chance to make much progress lately

💬 pinheadmz commented on issue "Remove libevent as a dependency (HTTP / cli / torcontrol)":
(https://github.com/bitcoin/bitcoin/issues/31194#issuecomment-2462383710)
There is a Signal working group for this project as well if anyone wants in lemme know

💬 0xB10C commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#discussion_r1832803900)
> One solution could be to update the current tracepoint to a TRACE8 and have a bool argument indicating if tx_or_package_hash is a tx or package hash with m_subpackage.m_changeset->GetTxCount() == 1.

This could look like e.g. https://github.com/0xB10C/bitcoin/commit/2eb1410e774636040d19d3baf5e22b2e4a8fbfd2

👋 andrewtoth's pull request is ready for review: "validation: fetch block inputs on parallel threads ~17% faster IBD"
(https://github.com/bitcoin/bitcoin/pull/31132)

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads ~17% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-2462468543)
@furszy I tried to switch to using a shared threadpool, but it is much slower that way. We need a way to have shared state between threads for this, instead of just scheduling tasks. I suppose the generic threadpool is great for scheduling independent tasks like indexing an individual block, but for quickly pulling outpoints off a shared vector it is not optimized well.

From https://github.com/bitcoin/bitcoin/issues/29386:
> I just [noticed the comment in the code](https://github.com/bitcoin
...

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads ~17% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r1832842632)
I changed the batch size to be number of workers.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads ~17% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r1832843082)
Added a benchmark to experiment with these.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads ~17% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r1832843202)
Done.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads ~17% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r1832844237)
Added tests and benchmark.
The test has random parameters, one of which would be end up having a single worker thread.

💬 marcofleon commented on pull request "fuzz: Fix difficulty target generation in `p2p_headers_presync`":
(https://github.com/bitcoin/bitcoin/pull/31213#discussion_r1832862629)
Agreed, it should be clear where the hardcoded values are coming from. It doesn't seem necessary to call `SetCompact` every iteration, so I decided to explain in the comment above. Let me know what you think.

💬 mzumsande commented on pull request "fuzz: fix bad alloc in connman target":
(https://github.com/bitcoin/bitcoin/pull/31235#discussion_r1832895547)
Since there was a bug somewhere if we ever send `max_pct > 100` (with privacy implications, the reason `max_pct` exists is not to reveal the entire addrman), why not `Assume(max_pct <=100)` / adjust the fuzzer range instead of trying to accommodate it? There is a difference between `max_pct` and the `max_addresses` where a caller could legitimately ask for more addresses than addrman has because they don't know current addrman size - no caller should ever ask for more than 100%.