💬 SparK-Cruz commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657183466)
The fact RBF is possible already undermines the security of the mempool, which was already low, so having it on by default or not, the fact it exists already killed zero-conf a long time ago.

👋 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
...