💬 purpleKarrot commented on pull request "kernel: create monolithic kernel static library":
(https://github.com/bitcoin/bitcoin/pull/33077#issuecomment-3126699812)
I think we should reduce the amount of "clever hacks" in the CMake code, not increase them. If `.pc` files are not expressive enough for exporting all our target properies (and they will never be, because `.pc` files are not relocatable), we should stop providing them and export target information as CMake packages only. If CMake packages are not expressive enough either, because we don't want to export dependencies in case of a static library, we should simply not export a static library to a p
...

💬 Bost commented on pull request "guix: accomodate migration to codeberg":
(https://github.com/bitcoin/bitcoin/pull/32439#issuecomment-3126767151)
@maflcko Thank. Also I found that reducing parallelism (e.g. to 4 cores) does the trick:
```
bost@ecke ~$ guix build --cores=4 bitcoin-core --no-grafts --check
…
successfully built /gnu/store/fc849g9lg1d970plrf0zgx0qlhykb2nx-bitcoin-core-28.2.drv
/gnu/store/x49mxs1m10b7hnav9sh85yqg42wc7az5-bitcoin-core-28.2
```
(The `--no-grafts` and `--check` flags ensure that Guix rebuilds the package locally rather than using substitutes.)

🤔 janb84 reviewed a pull request: "doc: Add legacy wallet removal release notes"
(https://github.com/bitcoin/bitcoin/pull/33075#pullrequestreview-3062133613)
ACK fa21a90c3558c8414aafe0e5b68d8b9590cca127

PR adds a release note for several related legacy wallet removal PR's

💬 hebasto commented on pull request "kernel: create monolithic kernel static library":
(https://github.com/bitcoin/bitcoin/pull/33077#issuecomment-3126883402)
> Currently, when clients want to use bitcoin as a suproject, they get their build-type and compile flags silently changed, and they get a summary spewed into their configure log. This is what should be fixed instead.

These ideas are orthogonal to this PR, aren't they?

💬 willcl-ark commented on pull request "guix: warn SOURCE_DATE_EPOCH set in guix-codesign":
(https://github.com/bitcoin/bitcoin/pull/33073#issuecomment-3126963884)
My guix build with this change:

```
src/core/bitcoin on  codesign-source-epoch [$] via △ v3.31.6 via 🐍 v3.13.3 via ❄️ impure (nix-shell-env) took 1h33m13s
❯ find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
b8961023686b6aa3cef95f9f938c1c4b9c1e87945ea60c994dbe56c430faf43e guix-build-1bed0f734b3f/output/aarch64-linux-gnu/SHA256SUMS.part
90f9c040b2640cc7840cdb9341170c754b107ef7c681c762e8d69e3641378322 guix-build-1bed0f7
...

💬 willcl-ark commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3126974485)
FWIW the CI run taking place [here in this PR](https://github.com/bitcoin/bitcoin/actions/runs/16567612264?pr=32989) is using Cirrus Runners on the migrated jobs (thanks @fkorotkov !) and demonstrates an absolute worst-case runtimeof these jobs with:

- No docker build cache
- No ccache cache
- No depends-sources caches
- No depends-build caches

💬 theStack commented on pull request "rpc, wallet: replace remaining hardcoded output types with `FormatAllOutputTypes`":
(https://github.com/bitcoin/bitcoin/pull/33065#issuecomment-3127061118)
> Nit: can update the grep command in the PR description.

Done.

🚀 fanquake merged a pull request: "rpc, wallet: replace remaining hardcoded output types with `FormatAllOutputTypes`"
(https://github.com/bitcoin/bitcoin/pull/33065)

👍 theStack approved a pull request: "RPC: Return `permitbaremultisig` and `maxdatacarriersize` in `getmempoolinfo`"
(https://github.com/bitcoin/bitcoin/pull/29954#pullrequestreview-3062535291)
ACK 1c10b7351e194fc788766347f65f4512f61f05e8

💬 marcofleon commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2236368139)
I'm seeing a couple of potential reasons. First, when we receive an announcement from a non-wtxid-relay peer, we put that inv's hash (a txid) into the known inventory. And then second, when we receive an orphan we add the parent txids that we don't already have into that peer's known inventory.

💬 glozow commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2236464694)
You're right. Might think about this some more but would be out of scope here anyway. Resolving!

💬 glozow commented on pull request "refactor: GenTxid type safety followups":
(https://github.com/bitcoin/bitcoin/pull/33005#discussion_r2236460557)
Might be worth a comment because non-obvious: `m_tx_inventory_known_filter` hashes are based on the wtxidrelay-ness of the peer, so it's important that we compare the hash from `inv` and not the wtxid that was in `m_tx_inventory_to_send`.

🚀 glozow merged a pull request: "RPC: Return `permitbaremultisig` and `maxdatacarriersize` in `getmempoolinfo`"
(https://github.com/bitcoin/bitcoin/pull/29954)

📝 stickies-v opened a pull request: "kernel: improve BlockChecked ownership semantics"
(https://github.com/bitcoin/bitcoin/pull/33078)
Subscribers to the BlockChecked validation interface event may need
access to the block outside of the callback scope. Currently, this
is only possible by copying the block, which makes exposing this
validation interface event publicly either cumbersome or with significant
copy overhead.

By using shared_ptr, we make the shared ownership explicit and allow
users to safely use the block outside of the callback scope.

📝 fanquake opened a pull request: "ci: limit max stack size to 512 KiB"
(https://github.com/bitcoin/bitcoin/pull/33079)
Picks up #31367.
Closes #29840.

Limit adjustment is moved until after compilation, otherwise compilation might not succeed.
I've used compilation flags to limit the stack size in the native macOS jobs, because trying to use `ulimit` resulted in:
```bash
+ '[' -n 1 ']'
+ ulimit -s 262144
/Users/runner/work/bitcoin/bitcoin/ci/test/03_test_script.sh: line 17: ulimit: stack size: cannot modify limit: Operation not permitted
```

💬 fanquake commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/31367#issuecomment-3127294235)
PIcked up in #33079.

💬 pablomartin4btc commented on pull request "doc: Add legacy wallet removal release notes":
(https://github.com/bitcoin/bitcoin/pull/33075#discussion_r2236527647)
nit: `newkeypool` was already mentioned earlier...
```suggestion
`dumpwallet`, `importwallet` and `upgradewallet` are removed.
```

💬 purpleKarrot commented on pull request "kernel: create monolithic kernel static library":
(https://github.com/bitcoin/bitcoin/pull/33077#issuecomment-3127368986)
> These ideas are orthogonal to this PR, aren't they?

From the perspective of the implementation, yes. From the perspective of the client, no.

A client may want to build an application that links the kernel. There are two options: One is to import the kernel package, the other is to build the kernel as a subproject. If the client prefers to statically link the kernel, option two should be preferred. This PR optimizes for option one.

💬 ishaanam commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2236689505)
Oh, that makes sense, I thought that you were talking about changing the if-statement on line 393.

💬 enirox001 commented on pull request "test: add option to skip large re-org test in feature_block":
(https://github.com/bitcoin/bitcoin/pull/33003#issuecomment-3127476258)
tACK 8810642 – Ran tests with/without --skipreorg; saw ~40 % speedup; no regressions.