💬 vasild commented on pull request "fuzz: set the output argument of FuzzedSock::Accept()":
(https://github.com/bitcoin/bitcoin/pull/31316#issuecomment-3355567303)
Closing this because https://github.com/bitcoin/bitcoin/pull/28584 was merged which includes the commit in this PR.

This PR: 83199523c90591d57cd5046212c878a4d54d621d
#28584 contains: e883b37768812d96feec207a37202c7d1b603c1f

```sh
$ git range-diff e883b37768~..e883b37768 83199523c9~..83199523c9
1: e883b37768 = 1: 83199523c9 fuzz: set the output argument of FuzzedSock::Accept()
$
```

💬 stickies-v commented on pull request "build: Drop support for EOL macOS 13":
(https://github.com/bitcoin/bitcoin/pull/33489#issuecomment-3355697586)
re-ACK 1aaaaa078bb2efed126e3f41ecf7c81ccf005818

👍 vasild approved a pull request: "test: fix p2p_leak_tx.py"
(https://github.com/bitcoin/bitcoin/pull/33121#pullrequestreview-3288480537)
ACK 14ae71f323dd011c6d51470ea15cf00750970f65

👍 hebasto approved a pull request: "ci: Remove bash -c from cmake invocation using eval"
(https://github.com/bitcoin/bitcoin/pull/33401#pullrequestreview-3288490644)
ACK 50194029e7c2581b751931080f5999785a39929f.

🚀 hebasto merged a pull request: "ci: Remove bash -c from cmake invocation using eval"
(https://github.com/bitcoin/bitcoin/pull/33401)

💬 stratospher commented on pull request "validation: remove BLOCK_FAILED_CHILD":
(https://github.com/bitcoin/bitcoin/pull/32950#discussion_r2394150885)
done.

💬 stratospher commented on pull request "validation: remove BLOCK_FAILED_CHILD":
(https://github.com/bitcoin/bitcoin/pull/32950#discussion_r2394151442)
ah I see how it could be confusing, clarified it to "since the previous commit removes BLOCK_FAILED_CHILD usage in InvalidateBlock"

💬 stratospher commented on pull request "validation: remove BLOCK_FAILED_CHILD":
(https://github.com/bitcoin/bitcoin/pull/32950#discussion_r2394152350)
good point. I've removed it since `BLOCK_FAILED_MASK = 96` is never written to disk but only used while reading BlockStatus values. if 96 exists on disk, it is the responsibility of `BLOCK_FAILED_VALID` and `BLOCK_FAILED_CHILD` and we have dealt with those cases.

💬 stratospher commented on pull request "validation: remove BLOCK_FAILED_CHILD":
(https://github.com/bitcoin/bitcoin/pull/32950#discussion_r2394152594)
done.

💬 trevarj commented on pull request "guix: update time-machine to 5cb84f2013c5b1e48a7d0e617032266f1e6059e2":
(https://github.com/bitcoin/bitcoin/pull/33185#issuecomment-3355880463)
> Hopefully Guix makes a release tag again one day.

This is coming soon, there have been talks of it.

In the meantime, you can simply `guix pull` and receive the freshest version (from master). If you don't want master, you can edit your Guix channels (`~/.config/guix/channels.scm`) and pin the commit to something "stable".

I'm not certain that would cause an issue though. To me it just sounds like unstable substitute servers. For context, if you try installing Guix System it could tak
...

👍 stickies-v approved a pull request: "[28.x] backports + 28.3rc1"
(https://github.com/bitcoin/bitcoin/pull/33476#pullrequestreview-3288706062)
re-ACK 9968b15937cbc2071c3474bd83f9c9fb4bb3a970

Getting the same bitcoin.conf example.

💬 stickies-v commented on pull request "[28.x] backports + 28.3rc1":
(https://github.com/bitcoin/bitcoin/pull/33476#discussion_r2394279590)
Oh I see. The fact that test functions are slightly renamed combined with this patch of code being ~duplicated tripped me up a bit. Thanks for the clarification, can be marked as resolved.

🤔 sipa reviewed a pull request: "validation: remove BLOCK_FAILED_CHILD"
(https://github.com/bitcoin/bitcoin/pull/32950#pullrequestreview-3288768556)
Concept ACK

⚠️ venpisey12 opened an issue: "0968812058"
(https://github.com/bitcoin/bitcoin/issues/33513)

✅ willcl-ark closed an issue: "0968812058"
(https://github.com/bitcoin/bitcoin/issues/33513)

💬 sipa commented on issue "Mempool Expiry eviction might remove txs that could be mined in the next block":
(https://github.com/bitcoin/bitcoin/issues/33510#issuecomment-3356193889)
@davidgumberg I like the idea of expiring based on how many times a transaction was expected to be mined, but wasn't. E.g. every block, or every 10 minutes, or on a Poisson timer, run the block building code and increase a counter in the mempool for every transaction. Whenever the counter reaches a certain configurable value, expire. Note that that may well mean that nothing ever expires, if everything gets mined once it's spent enough time near the top of the mempool - but that may be ok, if it
...

💬 sipa commented on pull request "p2p: Use network-dependent timers for inbound inv scheduling":
(https://github.com/bitcoin/bitcoin/pull/33464#issuecomment-3356266112)
utACK 0f7d4ee4e8281ed141a6ebb7e0edee7b864e4dcf

As a follow-up, I think we can give every outbound onion connection a separate network_id, because they all look distinct to external observers.

💬 sipa commented on pull request "[IBD] precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2394589493)
In commit "optimization: Cache PresaltedSipHasher in CBlockHeaderAndShortTxIDs"

Why is this optional? It looks like it's always initialized in the constructor.

💬 m3dwards commented on pull request "ci: fix buildx gha cache authentication on forks":
(https://github.com/bitcoin/bitcoin/pull/33508#issuecomment-3356349768)
> But IMO exporting all variables prefixed with `ACTIONS_` to the CI env should not ever be problematic (and my insulate us a little in case new variables are introduced).

Which is what I think happened here to make this break in the first place so I'd support exporting all `ACTIONS_` vars.

💬 sipa commented on pull request "p2p: Mitigate GETADDR fingerprinting by setting address timestamps to a fixed value":
(https://github.com/bitcoin/bitcoin/pull/33498#issuecomment-3356355027)
Concept ACK