👍 darosior approved a pull request: "Introduce per-txin sighash midstate cache for legacy/p2sh/segwitv0 scripts"
(https://github.com/bitcoin/bitcoin/pull/32473#pullrequestreview-3067897201)
ACK fb7e9decf3f12ebae786e0cecf2f24a91c6e9d4c

💬 delta1 commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3132877399)
> should probably lower all three settings, not just the one. However, this breaks a dozen tests or so, there seem to be some more missing that it should be breaking, and feerate estimation currently doesn’t do below 1 s/vB

@murchandamus I'm busy with this to make some progress while @RobinLinus is away, what's the process - create a new PR as a continuation of this one?

When you say "there seem to be some more missing that it *should* be breaking" - what do you mean?

💬 willcl-ark commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3132892840)
I pushed a commit to make a cache save on pull requests, and then a force push dropping that commit. This worked, but I do see some unexpected ccache hit rates... not sure if anyone here might have an idea about it; I'm at a bit of loss about what could be going wrong here to be honest.

In e.g. the `previous releases` job, the cache was saved here: https://github.com/bitcoin/bitcoin/actions/runs/16589926678/job/46922852038?pr=32989#step:9:77

> Sent 426321843 of 426321843 (100.0%), 81.3 MBs
...

👍 dergoegge approved a pull request: "ci: limit max stack size to 512 KiB"
(https://github.com/bitcoin/bitcoin/pull/33079#pullrequestreview-3067953326)
utACK 3b23f95e3463bf0ab5e293654bb362d07330ff9a

Limiting the stack size in the fuzz job would also be nice but can be left for a follow up.

👍 pinheadmz approved a pull request: "index: initial sync speedup, parallelize process"
(https://github.com/bitcoin/bitcoin/pull/26966#pullrequestreview-3067959910)
re-ACK 9bba5ef0cc5b6890eba2be3a6ed429c4fea5a28f

Changes since last review are minimal responses to my own review suggestions. Built on macos/arm64 and debian/x86. Ran functional and unit tests, ran with `-indexworkers=16` on mainnet fullnode with >900000 blocks

<details><summary>Show Signature</summary>

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

ACK 9bba5ef0cc5b6890eba2be3a6ed429c4fea5a28f
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmiI39
...

💬 pinheadmz commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2240120761)
This is bike shedding now so ok to ignore -- but when we set thread names on Linux they are truncated to 15 characters. So I dunno I guess "thread" and "worker" are redundant in the name of a thread?

https://github.com/bitcoin/bitcoin/blob/2f410ad78c767e37f083d03114f6661b73647af3/src/util/threadnames.cpp#L22-L27

<img width="692" height="317" alt="image" src="https://github.com/user-attachments/assets/8819caee-2731-462c-a914-c595a8599000" />

💬 maflcko commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3132951884)
> I'm not sure exactly what is causing the misses here; I would expect this to be 100% (or 99.x%) which I have seen previously.

ccache does not work when the code changes, so you'll have to make sure to compile the same code (usually commit id). Ref:

* https://github.com/bitcoin/bitcoin/actions/runs/16589926678/job/46922852038?pr=32989#step:2:89 [e115ce1e8089037e2bde27600fb092425b0c461d] vs
* https://github.com/bitcoin/bitcoin/actions/runs/16595726917/job/46941763412?pr=32989#step:2:89 [a
...

💬 1440000bytes commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3132966314)
> Since similar arguments keep coming up: The sole purpose of the minimum relay fee should be DoS protection. Trying to fix the security budget by imposing administered prices on block space seems misguided—market forces will likely circumvent such price controls and make things worse in the process.

This does make it easier for an attacker to use bitcoin p2p as messaging layer. Malwares already use [DNS TXT records](https://dti.domaintools.com/malware-in-dns/) for it although bitcoin p2p wou
...

💬 TheCharlatan commented on pull request "kernel: create monolithic kernel static library":
(https://github.com/bitcoin/bitcoin/pull/33077#issuecomment-3132971911)
> But if we want to make sure that 3rd parties use a deterministically built kernel, we either need to force them to use a dynamic library or to build their application inside the same deterministic build environment.

I don't think we should force anything. If we try to, people will find worse ways to get around this limitation, e.g. by manually picking source files out of the repository and creating the library that way (which they did for libbitcoinconsensus). That said, releasing a shared
...

💬 ryanofsky commented on pull request "kernel: create monolithic kernel static library":
(https://github.com/bitcoin/bitcoin/pull/33077#issuecomment-3132978479)
> **We cannot provide packages that contain static libraries and/or `.pc` files.**

Oh, that makes sense to me. I thought you might have been objecting to having code in the build system that generates .pc files. But I agree distributing .pc files with precompiled static libraries does not seem like it would be very useful, and I assume most developers would just compile from source. Would be interested to know more if this is incorrect and anyone is asking for static binaries or would find th
...

⚠️ mraassina34 opened an issue: "PROFESSIONAL BITCOIN RECOVERY EXPERT META TECH RECOVERY PRO"
(https://github.com/bitcoin/bitcoin/issues/33089)
### Please describe the feature you'd like to see added.

I am Mel Raassina, an Australian citizen. I am recounting my ordeal in the hopes of preventing others from becoming victims of crypto investment fraud. A few months ago, I was ensnared by a deceptive crypto investment scheme connected to a brokerage firm. I had made a substantial investment when Bitcoin prices were appreciating, believing it to be a sound venture. Regrettably, I was defrauded of AUD 420,000, and the broker subsequently bl
...

💬 fanquake commented on pull request "ci: limit max stack size to 512 KiB":
(https://github.com/bitcoin/bitcoin/pull/33079#discussion_r2240182138)
Given it's in miniscript tests, I'm assuming it was "fixed" in the same refactor as msan. Will check in any case.

✅ fanquake closed an issue: "PROFESSIONAL BITCOIN RECOVERY EXPERT META TECH RECOVERY PRO"
(https://github.com/bitcoin/bitcoin/issues/33089)

💬 sipa commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3132991908)
Concept ACK.

💬 fanquake commented on pull request "doc: move `cmake -B build -LH` up in Unix build docs":
(https://github.com/bitcoin/bitcoin/pull/33088#issuecomment-3132995620)
@stickies-v might follow up with any Windows doc changes.

🚀 fanquake merged a pull request: "doc: move `cmake -B build -LH` up in Unix build docs"
(https://github.com/bitcoin/bitcoin/pull/33088)

✅ fanquake closed an issue: "ci: Lower and unify default stack size"
(https://github.com/bitcoin/bitcoin/issues/29840)

🚀 fanquake merged a pull request: "ci: limit max stack size to 512 KiB"
(https://github.com/bitcoin/bitcoin/pull/33079)

👍 fanquake approved a pull request: "guix: warn SOURCE_DATE_EPOCH set in guix-codesign"
(https://github.com/bitcoin/bitcoin/pull/33073#pullrequestreview-3068095587)
ACK 1bed0f734b3f2dd876193b5cad303bfab1d250d5

💬 willcl-ark commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3133043442)
> This means the code was [953c90d](https://github.com/bitcoin/bitcoin/commit/953c90d7649c076e6e43418f50c33b3ae5f82608) vs [3219847](https://github.com/bitcoin/bitcoin/commit/321984705dbcc5982013c8cfb52389cf3f2e75f6)

Dang, I must have rebased on upstream/master (out of habit) to drop that top commit. Thanks for catching.