📝 hebasto opened a pull request: "ci: Run "macOS native x86_64" job on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28187)
From https://github.com/bitcoin/bitcoin/issues/28098:
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.

> If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.

Historical context:
- https://github.com/bitcoin/bitcoin/pull/17697
- https://github.com/bitcoin/bitcoin/issues/17803
- https://github.com/bitcoin/bitcoin/pull/18031

Security concerns:
- https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-16514321
...

💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1657245667)
Two PRs are aiming to address this issue:
- #28173
- #28187

💬 fanquake commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657246934)
This is replacing the arm64 job with an x86_64 job?

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657247268)
> This is replacing the arm64 job with an x86_64 job?

Yes. No `arm64` macOS images are available in GitHub Actions for now.

💬 fanquake commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657248139)
The PR description should probably mention that, as it's a regression in terms of testing. i.e no-longer testing on Apples primarily supported hardware.

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657249053)
> The PR description should probably mention that, as it's a regression in terms of testing. i.e no-longer testing on Apples primarily supported hardware.

Done.

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278617031)
I considered that, but wouldn't it be pretty self-evident from the address format? happy to add if it still feels useful.

📝 hebasto opened a pull request: "ci: Use documented `CCACHE_MAXSIZE` instead of `CCACHE_SIZE`"
(https://github.com/bitcoin/bitcoin/pull/28188)
This PR aims to:
1) Remove our own `CCACHE_SIZE` environment variable that violates Ccache's `CCACHE_*` namespace.
2) Introduce the `CCACHE_MAXSIZE` environment variable that is documented since [v3.3](https://ccache.dev/manual/3.3.html), which makes its usage consistent with other ones, such as `CCACHE_DIR` and `CCACHE_NOHASHDIR`.
3) Increase verbosity of the `ccache --show-stats` command output.

💬 hebasto commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#issuecomment-1657264383)
Concept ACK.

💬 TheBlueMatt commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657268865)
> This is helpful for second layer protocols, including Lightning.

I'm not aware of any second layer protocols that are improved by having full-rbf more broadly available.

💬 pox commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657277622)
Users who care about full-RBF and want it already have it turned on.

This change does not impact them.

This change has the most impact on:

1. Users who don't care about full-RBF.
2. Users who do care and want full-RBF to be **off** and rely on defaults not changing.

In other words, it impacts most those that want it least. That seems like a questionable precedent.

Regardless of how much full-RBF is desirable, changing defaults incentivizes users to avoid upgrades and over-specify
...

💬 darosior commented on issue "test: 999 of 999 multisig":
(https://github.com/bitcoin/bitcoin/issues/28179#issuecomment-1657278761)
For what it's worth we already test a 1-of-N `multi_a` where N is randomly picked from [1; 999]:
https://github.com/bitcoin/bitcoin/blob/64440bb733896a7a2caf902825e0406cb993e666/test/functional/wallet_taproot.py#L495-L501

Also:
> The stack size limit of 1000 [confuses even those who designed it](https://bitcoin.stackexchange.com/questions/117317/how-can-i-create-a-multi-sign-for-a-large-number-of-users/117320?noredirect=1#comment134168_117320).

The stack limit was introduced by Satoshi i
...

📝 amitiuttarwar opened a pull request: "p2p: diversity network outbounds follow-ups"
(https://github.com/bitcoin/bitcoin/pull/28189)
builds on #27213 and addresses outstanding review comments

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1657295575)
thank you for the reviews everyone 🙌

In terms of next steps, we could either keep this PR as is in aims of merging soon & address follow-ups separately, or incorporate the review comments here. I've recapped the current status of the PR and am curious to hear feedback as to what route seems preferable.

* the current tip on this PR has 3 review ACKs ([vasild](https://github.com/bitcoin/bitcoin/pull/27213#pullrequestreview-1516160146), [mzumsande](https://github.com/bitcoin/bitcoin/pull/
...

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278638362)
incorporated brace initialization in [`4428c6d` (#28189)](https://github.com/bitcoin/bitcoin/pull/28189/commits/4428c6d25b9a9a0cbcb6ff01525fe2d751b7a5aa)

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278638425)
updated in [`4428c6d` (#28189)](https://github.com/bitcoin/bitcoin/pull/28189/commits/4428c6d25b9a9a0cbcb6ff01525fe2d751b7a5aa)

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278639092)
for anyone following along in review, some historical context of why it was initially changed from `std::array` to `std::unordered_map` here: https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1242196931

@ajtowns I agree with your reasoning in https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1253827052 that an array doesn't tangibly make the code more brittle. since an array has a significantly smaller memory footprint, I think it's slightly preferable. incorporated in [`8449
...

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278639126)
updated in [`84495cd` (#28189)](https://github.com/bitcoin/bitcoin/pull/28189/commits/84495cd2a8d12121b3164d20bd6b7c87a9ef43e2) by turning `m_network_counts` to an array

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278639150)
done in [`006b8dd` (#28189)](https://github.com/bitcoin/bitcoin/pull/28189/commits/006b8dd3e6a161932a376a3988b5531410fa88a1)

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#issuecomment-1657297571)
@mzumsande - release note added in [`a6d270d` (#28189)](https://github.com/bitcoin/bitcoin/pull/28189/commits/a6d270db4238c48a7a1a70e4398f2b33a97ed037)

💬 BitcoinMechanic commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657332489)
> Replace by fee makes double spending easier and harm's Bitcoin's ability to be used as a currency in my opinion

RBF also allows people to be more frugal with their fee estimates as they can bump more easily if necessary - this certainly helps bitcoin's ability to be used a currency.

Moreover, it has never been appropriate to rely on unconfirmed transactions. Maintaining an illusion (that transactions that aren't in the blockchain can be relied upon) is not something worth attempting by f
...