💬 fanquake commented on pull request "guix: use GCC 14.3.0 over 13.3.0":
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3491797678)
Windows is non-deterministic across x86_64 && aarch64.
Guix build (aarch64):
```bash
6c31a0f19daec94c3d629e50d6bc2461ceb6e0fbb0823cb10a40bc735e37f9b5 guix-build-25ede968bada/output/aarch64-linux-gnu/SHA256SUMS.part
f3ba2f0c5f1d99d377ea11ea2b9983187192d733c7db444060d112d1be48ecd2 guix-build-25ede968bada/output/aarch64-linux-gnu/bitcoin-25ede968bada-aarch64-linux-gnu-debug.tar.gz
321db43f3a4327287813274b7f9874fb76799643fdc9cbbc9ee13bce10b6e004 guix-build-25ede968bada/output/aarch64-linux-
...

📝 vasild opened a pull request: "test: move create_malleated_version() to messages.py for reuse"
(https://github.com/bitcoin/bitcoin/pull/33793)
Move `create_malleated_version()` from `p2p_orphan_handling.py` to `test_framework/messages.py` so that it can be reused by other tests.

---

This is part of [#29415 Broadcast own transactions only via short-lived Tor or I2P connections](https://github.com/bitcoin/bitcoin/pull/29415). Putting it in its own PR to reduce the size of #29415 and because it does not depend on the other commits from there.

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3491839226)
Extracted two more commits into separate smaller PRs for easier review:

https://github.com/bitcoin/bitcoin/pull/33792
https://github.com/bitcoin/bitcoin/pull/33793

👍 theStack approved a pull request: "Bugfix: QA: rpc_bind: Skip nonloopback test if no such address is found"
(https://github.com/bitcoin/bitcoin/pull/33433#pullrequestreview-3422901949)
Tested ACK 79b4c276e7b9b526fa8f563b1e09b2b970baece6

Verified also in a local branch rebased on master, given that the merge-base is extremely old (>7 years).

💬 laisial commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3492055411)
> DNS seeds still pose **a small amount of risk** for the network. As such, DNS seeds must be **run by entities which have some minimum level of trust within the Bitcoin community**. (DNS policy)

this discussion is inherently personal with the question being how much 'some minimum level of trust' is.

> Luke: as for trust within the Bitcoin community, generally it seems **I am much more trusted than some of the other DNS seed operators**. Indeed, it probably makes sense to intentionally continu
...

👍 stickies-v approved a pull request: "util: Allow Assert() in contexts without __func__"
(https://github.com/bitcoin/bitcoin/pull/33785#pullrequestreview-3423080904)
ACK fae1d99651e29341e486a10e6340335c71a2144e

Note that this also introduces behaviour change by including the entire function signature instead of just the name. Might be worth mentioning in OP.

💬 maflcko commented on pull request "test: move create_malleated_version() to messages.py for reuse":
(https://github.com/bitcoin/bitcoin/pull/33793#issuecomment-3492252019)
review ACK 2bd155e6ee7e3cabd76083ac921b34bb45d98769 🍨

<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 2bd155e6ee7e
...

👍 brunoerg approved a pull request: "test: move create_malleated_version() to messages.py for reuse"
(https://github.com/bitcoin/bitcoin/pull/33793#pullrequestreview-3423238890)
ACK 2bd155e6ee7e3cabd76083ac921b34bb45d98769

💬 stringintech commented on pull request "validation: remove BLOCK_FAILED_CHILD":
(https://github.com/bitcoin/bitcoin/pull/32950#discussion_r2495351885)
Related to your discussion:

The cleanup check on line 466 assumes invalid chains on disk always start with `BLOCK_FAILED_VALID`, followed by descendants with `BLOCK_FAILED_CHILD`:

```cpp
if (!(pindex->nStatus & BLOCK_FAILED_VALID) && pindex->pprev && (pindex->pprev->nStatus & BLOCK_FAILED_VALID))
```

However, if we load a chain where the first invalid block is `BLOCK_FAILED_CHILD` (with a valid parent), none of the blocks in that chain would be cleaned up.

I'm not sure if this scen
...

💬 ismaelsadeeq commented on pull request "node: add `BlockTemplateCache`":
(https://github.com/bitcoin/bitcoin/pull/33421#discussion_r2495460002)
This is fixed now

💬 ismaelsadeeq commented on pull request "node: add `BlockTemplateCache`":
(https://github.com/bitcoin/bitcoin/pull/33421#discussion_r2495465245)
This is not possible I think because we need to pass a non const block further down.
I instead avoid the second copy by moving.
Let me know what you think

💬 hodlinator commented on pull request "refactor: avoid double hashing in `SourceLocationHasher`":
(https://github.com/bitcoin/bitcoin/pull/32939#issuecomment-3492515824)
> Since there are quite a few follow-ups in #32604, it might make sense to do them all in one (or at least larger, related PRs) instead of carving it out into dozens of small ones?

Just noting that this was done in #33011, in case anyone else also wonders.

💬 ismaelsadeeq commented on pull request "node: add `BlockTemplateCache`":
(https://github.com/bitcoin/bitcoin/pull/33421#issuecomment-3492547495)
I forced pushed from 084bfbc1ec7f8f64f54d231bb641285622311b59 to a3f0010c2062fc88720e7eae33694f2491c32ebe [2311b59..a3f001](https://github.com/bitcoin/bitcoin/compare/084bfbc1ec7f8f64f54d231bb641285622311b59..a3f0010c2062fc88720e7eae33694f2491c32ebe)
- We now avoid the second copy when submitting solution by moving the block by value when constructing the shared pointer https://github.com/bitcoin/bitcoin/pull/33421#discussion_r2486576551
- Removed the `operator=` in block assembler options an
...

💬 frankomosh commented on pull request "doc: add cmake help option in Windows build docs":
(https://github.com/bitcoin/bitcoin/pull/33789#discussion_r2495546955)
I think it needs to match the format in `doc/build-unix.md`.

💬 vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#discussion_r2495596406)
I considered this again. I like to have the `Assume()` for documentation purposes. But that would make it stricter compared to `master` and this is not the purpose of this PR. I mean - in `master` and in this PR as it is now the logic is "if there are more than 3, remove one". Yes, we do imply that there will not be more than 3 at the end, but asserting that (in dev-only `Assume()`) seems to be out of the scope of this PR. So, I will leave it as it is.

💬 vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#issuecomment-3492632122)
`4b3a2c2360...1a9274f391`: rebase due to conflicts

💬 l0rinc commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3492922390)
Would we add Luke as a DNS seed operator now, if that was the discussion instead?

💬 ajtowns commented on pull request "Relax standardness rules regarding CHECKMULTISIG":
(https://github.com/bitcoin/bitcoin/pull/33755#issuecomment-3493057300)
It would be good to add a test case that demonstrates scriptPubKeys of this form (baremultisig and possible multisig in p2sh, with valid key push prior to invalid key) are spendable.

I think creating these outputs became non-standard with #12460 (2018-04-05 merge date), which changed the checks for pubkeys in a bare multisig from a size between 33 and 65 bytes (inclusive) to an explicit check of 02/03-and-33-bytes or 04/06/07-and-65-bytes.

In trying to create a functional test to validate
...

💬 kevkevinpal commented on pull request "script: remove dead code in `CountWitnessSigOps`":
(https://github.com/bitcoin/bitcoin/pull/33786#issuecomment-3493137616)
ACK [24bcad3](https://github.com/bitcoin/bitcoin/pull/33786/commits/24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7)

💬 Sjors commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3493139664)
The only performant macOS machine I have is a laptop, so I would never use that for long running fuzzer jobs. I do want to be able to reproduce failures, but that's not at stake here.

If I ever want to add a new fuzz target, I don't mind trying it on a physical linux machine (virtualisation on Apple Silicon has often been a can of worms for me, though I haven't tried with fuzzing).

Not doing (1) does increase the barrier for macOS based developers to contribute fuzz code. I'm not sure how to c
...