🤔 w0xlt reviewed a pull request: "wallet, rpc: Remove deprecated balances from getwalletinfo and getunconfirmedbalance"
(https://github.com/bitcoin/bitcoin/pull/32721#pullrequestreview-2915146785)
ACK https://github.com/bitcoin/bitcoin/pull/32721/commits/19a2f0ca09b9b56485d21e309486906c26e8afcf

💬 sipa commented on pull request "Cluster linearization: separate tests from tests-of-tests":
(https://github.com/bitcoin/bitcoin/pull/30605#discussion_r2138844396)
Huh, I hit fuzz failures with this if I let it run for a while. Weird, will investigate.

📝 theuni opened a pull request: "Refactor: Redefine CTransaction equality to include witness data"
(https://github.com/bitcoin/bitcoin/pull/32723)
I stumbled upon the `CTransaction` comparison operators while refactoring some nearby code. I found it surprising and not at all obvious that two transactions would test equal even if their witness data differed. It seems like an unnecessary potential footgun. Fix that by comparing against wtxid rather than txid.

Outside of tests, there were only 3 users of these functions in the code-base:
- Its use in the mempool has been replaced with an explicit txid comparison, as that's a tighter const
...

💬 furszy commented on pull request "index: move disk read lookups to base class":
(https://github.com/bitcoin/bitcoin/pull/32694#discussion_r2138853635)
This reminds me to my own [comment](https://github.com/bitcoin/bitcoin/pull/24230/commits/707ff84981d7f61d467093cb0aec7eee55276c52#r1307972744) hehe. Will do it here.

💬 theuni commented on pull request "Refactor: Redefine CTransaction equality to include witness data":
(https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-2960706099)
Ping @achow101 and @glozow to check my assumptions about the wallet/mempool uses.

💬 l0rinc commented on pull request "improve MallocUsage() accuracy":
(https://github.com/bitcoin/bitcoin/pull/28531#issuecomment-2960748073)
As @LarryRuane noticed, the new address-diff test sometimes disagrees with `MallocUsage` on macOS and on sanitizer builds.

I had to read a bit to understand why - I never needed the gory details until now. 🙂

It seem to me that macOS's nano allocator, and the allocators used by TSan/ASan, store per-chunk metadata in shadow tables rather than inline with the user block. For example, this might be related to what we're seeing: https://github.com/aosm/libmalloc/blob/master/src/nano_malloc.c#L
...

💬 douglaz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2960761883)

> Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.

Both sides have engaged in loaded language; for instance, calling consensus-valid transactions “spam.” I have likewise seen disrespect from the pro-filter camp, including personal attacks on Core developers and on anyone w
...

💬 negatratoron commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2960786220)
I'm not even sure that data carrier transactions are spam in the first place. The blockchain is an immutable structure that can store arbitrary data trustlessly - maybe block space is the product. and bitcoins are the tokens you can use to buy block space. Maybe thinking of bitcoin as a pure "currency" in the first place was wrong, and it's actually a tool for recording information immutably in the public domain.

You can architect the blockchain to be able to store data at some rate, for so
...

💬 achow101 commented on pull request "Refactor: Redefine CTransaction equality to include witness data":
(https://github.com/bitcoin/bitcoin/pull/32723#issuecomment-2960797103)
`CWalletTx::IsEquivalentTo` needs to consider malleated txs as equivalent, so the original behavior of ignoring the scriptSigs and scriptWitness is intended.

💬 w0xlt commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2138916560)
Maybe a test in `src/test/util_tests.cpp` in `BOOST_AUTO_TEST_CASE(test_script_parsing)` would be good for consistency's sake.

💬 theStack commented on pull request "test: refactor: overhaul (w)txid determination for `CTransaction` objects":
(https://github.com/bitcoin/bitcoin/pull/32421#discussion_r2138926469)
Good point, decided to squash the two mentioned commits to get rid of the repeated renaming. I.e. both `.rehash()` and `.hash` calls/accesses of CTransaction instances are replaced with `.txid_hex` now in a single commit (ce83924237127fe6d32b63c362b57789e4628954).

🤔 w0xlt reviewed a pull request: "descriptors: MuSig2"
(https://github.com/bitcoin/bitcoin/pull/31244#pullrequestreview-2915269775)
Perhaps the description of the commits `script/parsing: Allow Const to not skip the found constant ` (https://github.com/bitcoin/bitcoin/pull/31244/commits/4b135f80d03c92fb522d1dcfd7d697aa0a4af626) and `util/string: Allow Split to include the separator` (https://github.com/bitcoin/bitcoin/pull/31244/commits/b89a937225ed217556b38e000ee5d1bf0b5952aa) could explain why these changes are necessary for the musig2 descriptor.

🚀 achow101 merged a pull request: "ci: Rewrite test-each-commit as py script"
(https://github.com/bitcoin/bitcoin/pull/32680)

💬 w0xlt commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2138939609)
Without proper context, it may not be clear that this aggregation specifically refers to a MuSig2 aggregation.
Perhaps a name change could make the purpose and use of the function clearer.
```suggestion
virtual std::vector<CPubKey> GetMuSig2AggregateParticipantPubkeys(const CPubKey& pubkey) const { return {}; }
```

💬 w0xlt commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2138945119)
I wonder if this function should have an output parameter for `agg_pk` (the MuSig-aggregated x-only public key) for future use, instead of considering it null.
But yes, for now, there is no use.

💬 davidgumberg commented on pull request "deps: Bump lief to 0.16.6":
(https://github.com/bitcoin/bitcoin/pull/32431#discussion_r2138952194)
Fixed, thanks for being persistent on this, not sure why or what I was doing wrong [earlier](https://github.com/bitcoin/bitcoin/pull/32431#discussion_r2080687125) to see this error.

💬 ariard commented on pull request "BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)":
(https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-2960899586)
> to go to write a full-explanation on the ML 🤷

well i went to publish a full write up of that on the ML, because I like James and he’s someone with integrity.

i think the problem is real, but don’t trust, verify.

💬 furszy commented on pull request "index: move disk read lookups to base class":
(https://github.com/bitcoin/bitcoin/pull/32694#discussion_r2139038922)
Pushed. Added it in a separate commit to avoid extending ryanofsky's commit further.

📝 w0xlt opened a pull request: "Musig2 tests"
(https://github.com/bitcoin/bitcoin/pull/32724)
Built on https://github.com/bitcoin/bitcoin/pull/31244

This PR adds explicit tests for Bitcoin Core's MuSig2 interface.

Any issues in musig2.{cpp,h} will likely also be caught by the descriptor tests, but having more detailed tests for the MuSig2 class itself improves test reporting/coverage.

It uses BIP 328 test vectors.

💬 sipa commented on pull request "Cluster linearization: separate tests from tests-of-tests":
(https://github.com/bitcoin/bitcoin/pull/30605#discussion_r2139065850)
Fixed!

The exception was that `SimpleCandidateFinder::FindCandidateSet` initialized `best` to be the entire set of remaining transactions, which are not necessarily connected. If the search then stops without ever finding a better subset (because `max_iterations` was hit), the entire set was returned.

💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2961231738)
> > Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.
>
> Both sides have engaged in loaded language; for instance, calling consensus-valid transactions “spam.” I have likewise seen disrespect from the pro-filter camp, including personal attacks on Core developers and on anyo
...