💬 kosuodhmwa commented on issue "ZMQ problem: 'ss -ltnp | grep 28332' and 'ss -ltnp | grep 28333' does not give me an answer (i need it for LND)":
(https://github.com/bitcoin/bitcoin/issues/33710#issuecomment-3449181270)
additional info: bitcoin.conf:


additional info: bitcoin.conf:

```
whitelist=127.0.0.1

txindex = 1

proxy = 127.0.0.1:9050

listen = 1

bind = 0.0.0.0

server = 1

rpcbind=127.0.0.1
rpcbind=192.168.1.174

rpcallowip=127.0.0.1
rpcallowip=192.168.0.0/16

rpcport = 8332

rpcuser = MY_USER
rpcpassword = MY_PASS

wallet = mywallet
#wallet = cormorant

disablewallet=0

zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
```

💬 kosuodhmwa commented on issue "ZMQ problem: 'ss -ltnp | grep 28332' and 'ss -ltnp | grep 28333' does not give me an answer (i need it for LND)":
(https://github.com/bitcoin/bitcoin/issues/33710#issuecomment-3449182130)
So that entries exist... !?

zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3449216359)
Thank you @l0rinc for your detailed review and suggestions! I have taken some of them. The input fetcher has now been redesigned.
- Coins are written to the ephemeral cache that is created just to be used in `ConnectBlock`, instead of the main cache. This requires a new method in `CCoinsViewCache` - `GetPossiblySpentCoinFromCache`. Since we write to an empty cache instead of `CoinsTip()`, we could insert a `Coin` that exists in the db but is spent in `CoinsTip()`. Previously that insertion woul
...

📝 Ataraxia009 opened a pull request: "transaction: Adding script witness to ToString for CTxIn"
(https://github.com/bitcoin/bitcoin/pull/33711)
When debugging and trying to print the details of a `CTxIn` using the `ToString`, we get the `scriptSig`, but would also help to get the witness.

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-3450065966)
I have added an additional fuzz test (`clusterlin_sfl`) which verifies properties of the underlying data structure (`SpanningForestState`) plus sanity checks on it (as opposed to `clusterlin_linearize` which only tests the higher-level `Linearize()` function implemented in function of it).

It's no longer a net reduction in LoC now :(

👍 theStack approved a pull request: "test: Update BIP324 test vectors"
(https://github.com/bitcoin/bitcoin/pull/33688#pullrequestreview-3382329855)
ACK 51877f2fc5eb02b4229258b4b43731c4da843793

💬 Crypt-iQ commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2464867707)
> Should we only send SENDCMPCT hb=false after VERACK if we're not blocksonly?

I think this breaks -blocksonly nodes being able to send compact blocks since `m_provides_cmpctblocks` is never set? I can PR the -blocksonly change I suggested above separately if it's tangential.

💬 willcl-ark commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3450309523)
Guix hashes:

```
❯ find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
2f47825c394b4c4e9fe9495a2c0750ac34e78211391264d47ded7c676e78479a guix-build-c74705d81a88/output/aarch64-linux-gnu/SHA256SUMS.part
99a17c7dc93a17a344e53be8c1a19bb98f259a5387ff22f4f8e9af988a447128 guix-build-c74705d81a88/output/aarch64-linux-gnu/bitcoin-c74705d81a88-aarch64-linux-gnu-debug.tar.gz
b91f417b34b438db585c614780ae38bab35c3e313a1ac84ada8e090839
...

💬 ismaelsadeeq commented on pull request "refactor: rename `fees.{h,cpp}` to `fees/block_policy_estimator.{h,cpp}`":
(https://github.com/bitcoin/bitcoin/pull/33218#discussion_r2465012090)
fixed

💬 ismaelsadeeq commented on pull request "refactor: rename `fees.{h,cpp}` to `fees/block_policy_estimator.{h,cpp}`":
(https://github.com/bitcoin/bitcoin/pull/33218#issuecomment-3450374361)
Rebased and fixed a nit [diff](https://github.com/bitcoin/bitcoin/compare/c70781d4241cb8b30fe33e7205868382031b4670..1a7fb5eeeef3575c1e7c27915c9b98695191299d)

📝 sshivanshg opened a pull request: "serialize: Change GetSerializeSize return type to uint64_t"
(https://github.com/bitcoin/bitcoin/pull/33712)
GetSerializeSize currently returns size_t, which is platform-dependent. On 32-bit systems, size_t is 32-bit, limiting the maximum serialized size to ~4GB. This can cause integer overflow when multiplying by WITNESS_SCALE_FACTOR during block size validation.
Change GetSerializeSize to return uint64_t to ensure it can handle large sizes without overflow on all platforms.
This fixes CVE-2025-46597.
Resolves: #33709

💬 maflcko commented on pull request "refactor: rename `fees.{h,cpp}` to `fees/block_policy_estimator.{h,cpp}`":
(https://github.com/bitcoin/bitcoin/pull/33218#issuecomment-3450544165)
re-ACK 1a7fb5eeeef3575c1e7c27915c9b98695191299d 🐤

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK 1a7fb5eeeef3575c1e7c
...

💬 sshivanshg commented on issue "GetSerializeSize's return type should not be platform dependent":
(https://github.com/bitcoin/bitcoin/issues/33709#issuecomment-3450571633)
GetSerializeSize currently returns size_t, which is platform-dependent. On 32-bit systems, size_t is 32-bit, limiting the maximum serialized size to ~4GB. This can cause integer overflow when multiplying by WITNESS_SCALE_FACTOR during block size validation.
Change GetSerializeSize to return uint64_t to ensure it can handle large sizes without overflow on all platforms.

Resolves: #33709

🚀 fanquake merged a pull request: "test: Update BIP324 test vectors"
(https://github.com/bitcoin/bitcoin/pull/33688)

👍 maflcko approved a pull request: "Modernize custom filtering"
(https://github.com/bitcoin-core/gui/pull/899#pullrequestreview-3382860847)
review ACK 1a11cacf5225a7534155a9310a5647e7d4876076 🦋

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 1a11cacf5225
...

💬 maflcko commented on pull request "Modernize custom filtering":
(https://github.com/bitcoin-core/gui/pull/899#discussion_r2465200262)
nit: Not sure if it matters, but should this not move after the early return?

💬 fanquake commented on pull request "p2p: reduce false-positives in addr rate-limiting":
(https://github.com/bitcoin/bitcoin/pull/33699#issuecomment-3450653978)
cc @ajtowns

💬 maflcko commented on pull request "qa: Avoid knock-on exception in assert_start_raises_init_error":
(https://github.com/bitcoin/bitcoin/pull/32929#issuecomment-3450670707)
No objections, but in this case, it seems beneficial (or at least harmless) to list the init args, which could help debug why the init error was not raised?

💬 darosior commented on issue "GetSerializeSize's return type should not be platform dependent":
(https://github.com/bitcoin/bitcoin/issues/33709#issuecomment-3450700286)
This message from @sshivanshg is obviously LLM-generated. I'm not sure how to go about that. I am not comfortable with the idea of an LLM making changes to consensus-critical code. On the other hand, if the code is correct just closing the PR seems inappropriate.

⚠️ ramheat opened an issue: "Bitcoin <> Grin Atomic swaps to bypass censorship, Core-Knots Node debate"
(https://github.com/bitcoin/bitcoin/issues/33713)
### Please describe the feature you'd like to see added.

Integrate Mimblewimble (MW) as a consensus-friendly sidechain ([Grin](https://docs.grin.mw/wiki/introduction/grin-for-bitcoiners/)) or covenant-based extension to Bitcoin to enhance its long-term privacy, fungibility, and scalability. This would provide a trustless, cryptographic safeguard against the systemic risks of transactional surveillance, chain analysis, and the increasing centralization of mining and node operation.

### Is your
...