👋 hebasto's pull request is ready for review: "ci: Run Windows native task on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28173)

💬 hebasto commented on pull request "ci: Run Windows native task on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28173#issuecomment-1657189554)
> In the meantime it may be good to do 10 runs and then check how many of them fail

10 runs are green for the recent commit:
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/1
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/2
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/3
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/4
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/5
- http
...

📝 TheCharlatan opened a pull request: "kernel: Prune leveldb headers"
(https://github.com/bitcoin/bitcoin/pull/28186)
Leveldb headers are currently included in the `dbwrapper.h` file and thus available to many of Bitcoin Core's source files. However, leveldb-specific functionality should be abstracted by the `dbwrapper` and does not need to be available to the rest of the code. Having leveldb included in a widely-used header such as `dbwrapper.h` bloats the entire project's header tree.

The `dbwrapper` is a key component of the libbitcoinkernel library. Future users of this library would not want to contend
...

✅ Crypt-iQ closed an issue: "depends build fails macOS intel"
(https://github.com/bitcoin/bitcoin/issues/27977)

💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657206487)
@ariard

> So I’m Concept ACK on this change, I still think this change deserves announcement on the mailing list and usual technical communication channels to warn ecosystem stakeholders impacted by the proposed change.

I've posted a notice on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021823.html

Thanks for the Concept ACK!

💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1657208422)
> @ChristopherA wrote:
>
> > In my own case, current op_return limits keep me from posting a signed hash plus some metadata (<256 bytes) and thus I must use Taproot tricks instead.
>
> @petertodd wrote:
>
> > Large amounts of data are already published in the bitcoin blockchain in a variety of ways.
>
> This seems like something to propose on the bitcoin-dev mailinglist, like it was [ten years ago](https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/). You coul
...

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278586562)
I don't quite follow. if we have multiple networks that match, the randomization seems valuable in all the cases?

💬 sandakersmann commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657219473)
First-seen-safe is good enough for grocery shopping. But don't let me disturb you while you strip away the utility of BTC.

📝 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