💬 sipa commented on pull request "Cluster linearization: separate tests from tests-of-tests":
(https://github.com/bitcoin/bitcoin/pull/30605#issuecomment-2405669097)
Rebased after the merge of #30857.

⚠️ ArmchairCryptologist opened an issue: "Consider making 27.x Long-Term Support (LTS)"
(https://github.com/bitcoin/bitcoin/issues/31068)
### Please describe the feature you'd like to see added.

As mentioned in the patch notes for 28.x, since this release drops support for glibc older than 2.31, it will not run on several widely used Linux distros, including RHEL 8 and the RHELatives that base off of this, such as AlmaLinux 8 and Rocky Linux 8.

In case anyone is unaware, RHEL 8 and its derivatives are still supported, and will in fact not be EOL until 2029. While I don't have exact install numbers, I would not be surprised if
...

💬 TheCharlatan commented on pull request "kernel: Handle fatal errors through return values":
(https://github.com/bitcoin/bitcoin/pull/29642#issuecomment-2405736255)
I'm going to leave this in draft a little while longer. I think we should first focus on ryanofsky's #29700 though. If that is merged, there is always opportunity to revisit the approach taken here.

🤔 instagibbs reviewed a pull request: "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling"
(https://github.com/bitcoin/bitcoin/pull/29664#pullrequestreview-2360728484)
I took a bit of time to work on test coverage, with a rough branch here: https://github.com/instagibbs/bitcoin/commits/mzumsande_202403_near_tip_stalling/

last commit needs some clean up, but demonstrates some of the interplay of parallel blocks both compact and non-compact

💬 instagibbs commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#discussion_r1795674296)
It'd be better if this test(and others) actually complete the "chain sync" successfully up to known headers to e2e the test case. Perhaps it requests the next stalled block correctly, but it could fall over after.

💬 maflcko commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2405740263)
My understanding is that RHEL-8-like are still supported, if you manage to run a recent enough compiler on them and use that to compile Bitcoin Core yourself.

💬 maflcko commented on issue "ci: failure in win64 unit tests":
(https://github.com/bitcoin/bitcoin/issues/30792#issuecomment-2405785925)
Couldn't reproduce so far after https://github.com/bitcoin/bitcoin/pull/31067, but I'll keep trying.

💬 mzumsande commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#issuecomment-2405892467)
> I took a bit of time to work on test coverage, with a rough branch here: https://github.com/instagibbs/bitcoin/commits/mzumsande_202403_near_tip_stalling/
>
> last commit needs some clean up, but demonstrates some of the interplay of parallel blocks both compact and non-compact

Thanks!
I also worked on this yesterday/today and wrote a similar test, but added that as an `at_tip_stalling` subtest to `p2p_ibd_stalling.py` - while your test covering the logic in a similar way is in `p2p_co
...

💬 instagibbs commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#issuecomment-2405930127)
> while your test covering the logic in a similar way is in p2p_compactblocks.py. In which location do you think that it fits better (or even both?)?

I think your location is also fine, we're not testing that it works, just that it's being requested pretty much.

💬 davidgumberg commented on pull request "Don't zero-after-free `DataStream`: Faster IBD on some configurations":
(https://github.com/bitcoin/bitcoin/pull/30987#issuecomment-2405956954)
Fixed the spurious array bounds warning that occurs on Debian because it uses GCC 12.2, which has a bug where some uses of `std::vector::insert()` result in an incorrect array bounds warning, this issue was previously discussed in #30765. (See: https://github.com/bitcoin/bitcoin/commit/c78d8ff4cb83506413bb73833fc5c04885d0ece8)

As suggested by @theuni, I've added some benchmarks that help show where the performance improvement is coming from. In a test where a 1000-byte `CScript` is serialize
...

💬 brunoerg commented on pull request "net: option to disallow v1 connection on ipv4 and ipv6 peers":
(https://github.com/bitcoin/bitcoin/pull/30951#issuecomment-2405972129)
A mutation testing report for this PR is available at: https://brunoerg.xyz/mutation-core-front

🤔 naiyoma reviewed a pull request: "test: add test for specifying custom pidfile via `-pid`"
(https://github.com/bitcoin/bitcoin/pull/30724#pullrequestreview-2361352509)
Tested ACK [https://github.com/bitcoin/bitcoin/pull/30724/commits/04e4d52420a0e6bf40d4bd6fe1f31f66db9eab0a](https://github.com/bitcoin/bitcoin/pull/30724/commits/04e4d52420a0e6bf40d4bd6fe1f31f66db9eab0a)

💬 hodlinator commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1796096553)
Adding a dependency on *setup_common.h* is a case of making implicit dependencies explicit in my view. What the current version signifies is a different argument description (starting with "Run benchmarks " like the others) and a default directory value that *can't* be as clear as the original. We shouldn't be duplicating code snippets to avoid `#include`s. Even if it minimizes the size of this specific PR, going forward one has to make sure to keep both the original and duplicated place up to d
...

💬 theuni commented on pull request "Don't zero-after-free `DataStream`: Faster IBD on some configurations":
(https://github.com/bitcoin/bitcoin/pull/30987#issuecomment-2406059129)
> I also made a branch([davidgumberg@c832fed](https://github.com/davidgumberg/bitcoin/commit/c832feda63c586094193433a336b930147472285)) with a version of the zero after free allocator that keeps the compiler optimization prevention, but doesn't actually memset the stream to zero, and performance in some cases is only slightly better than master.

This is an interesting (and expected, I suppose) takeaway. Sadly, it suggests that there's really nothing that we can do to optimize our implementati
...

🤔 jonatack reviewed a pull request: "test: add end-to-end tests for CConnman and PeerManager"
(https://github.com/bitcoin/bitcoin/pull/26812#pullrequestreview-2361487622)
Light ACK 752fbab26aa67b01249ef5948d5c78e0e5a5244e per `git range-diff 489e5aa 612ba17 752fbab` since my previous ACK at https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-1613651346 and a quick re-read of the full changes rebased to current master. I like that the changes here are essentially limited to tests only.

💬 jonatack commented on pull request "rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats'":
(https://github.com/bitcoin/bitcoin/pull/29418#discussion_r1796164843)
```suggestion
if (key == "") {
if (key.empty()) {
```

💬 Wronskode commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2406165683)
This may causes problems if we have to open the port on the rooter ?

💬 jonatack commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2406179522)
> Currently, about 7% of my IPv4/IPv6 addrman entries use non 8333 port.

Same.

💬 furszy commented on pull request "wallet: optimize migration process, batch db transactions":
(https://github.com/bitcoin/bitcoin/pull/28574#issuecomment-2406197220)
@josibake @achow101 friendly ping. It seems we are quite close here.

⚠️ diivvy opened an issue: "BitcoinCore wallet not showing in my macbook "applications" after software update to macOS Sequoia 15.0.1 (24A348)"
(https://github.com/bitcoin/bitcoin/issues/31069)
Hello,
I have a macbook pro 2021 (1 TB) and this has been my primary device to store my bitcoins. I had downloaded bitcoin core wallet on this mac about 2-3 years ago ( I don't exactly remember when). It was working fine all this while but after this new mac update to Sequoia 15.0.1, I am unable to see the bitcoin core wallet on my mac. I can't see it on the "applications" or in the "finder" or in the "launchpad" of my mac.

I can see that the storage is still occupied in my mac worth about
...