💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2319894112)
Changed to `part_pubkeys`.

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2319894334)
Done

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2319894625)
Done

💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2319894903)
Done

💬 romanz commented on pull request "index: store per-block transaction locations for efficient lookups":
(https://github.com/bitcoin/bitcoin/pull/32541#discussion_r2319896447)
[94389c28e1...56e621d9f1](https://github.com/bitcoin/bitcoin/compare/94389c28e1068ffcc116614d16ac3047eb3068e3..56e621d9f16b3ed56089fa4760cf2b1b00a67362)

💬 romanz commented on pull request "index: store per-block transaction locations for efficient lookups":
(https://github.com/bitcoin/bitcoin/pull/32541#discussion_r2319897284)
94389c28e1...56e621d9f1

💬 darosior commented on pull request "kernel: chainparams & headersync updates for 30.0":
(https://github.com/bitcoin/bitcoin/pull/33274#discussion_r2319880154)
7 weeks ago :grimacing: just in case, heh?

🤔 darosior reviewed a pull request: "kernel: chainparams & headersync updates for 30.0"
(https://github.com/bitcoin/bitcoin/pull/33274#pullrequestreview-3181990147)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK 755152ac819a23acf2f9e70316134d74a04d589b. Verified assumevalid, chainwork and stats for mainnet, testnet4 and signet. Verified the serialized utxo set hash for mainnet. Haven't verified header params. Haven't verified for testnet3.
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEWQtykmla/6W2csuy4T/BRc0/QwQFAmi4kLsACgkQ4T/BRc0/
QwRjPQwArKJge7cs43ejKvvxbtsNtjDfc97jj1CnDtIEJuzKzglFzbdNh0/RY9ef
eAWh04+HhUv2FgNbCIL7PnWLletazPlW0GhTroRqhQsgU/
...

💬 w0xlt commented on pull request "doc: update multisig tutorial to use multipath descriptors":
(https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3250432274)
Concept ACK

💬 davidgumberg commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#issuecomment-3250442844)
I run a master node on mainnet with `debug=cmpctblock` and `logtimemicros=1`, and the average time between the "Initializing PartiallyDownloadedBlock" message at the [beginning](https://github.com/bitcoin/bitcoin/blob/689a32197638e92995dd8eb071425715f5fdc3a4/src/blockencodings.cpp#L57) of `InitData` and the "Initialized" message at the [end](https://github.com/bitcoin/bitcoin/blob/689a32197638e92995dd8eb071425715f5fdc3a4/src/blockencodings.cpp#L174) is 2.8ms, so the ~20% speedup here to `InitDa
...

💬 ryanofsky commented on issue "intermittent Segmentation fault in mptest IPC path (callFnAsyncParams)":
(https://github.com/bitcoin/bitcoin/issues/33277#issuecomment-3250471220)
This is probably caused by the disconnect-right-before-IPC-call-returns race condition described in https://github.com/bitcoin-core/libmultiprocess/issues/189 and fixed in https://github.com/bitcoin-core/libmultiprocess/issues/201

💬 ryanofsky commented on pull request "Add functional test for IPC interface":
(https://github.com/bitcoin/bitcoin/pull/33201#discussion_r2319974959)
re: https://github.com/bitcoin/bitcoin/pull/33201#discussion_r2319857067

> I've removed it; let's see where CI breaks.

Thanks! For reference, the error on ubuntu seems to be:

```
+ retry -- pip3 install --user pycapnp
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packag
...

💬 sipa commented on pull request "Add functional test for IPC interface":
(https://github.com/bitcoin/bitcoin/pull/33201#discussion_r2320004970)
Ok, added `--break-system-packages` back to the 4 CI jobs that failed as a result of removing it globally.

💬 willcl-ark commented on issue "ci: GHA fallback centos task runs out of space":
(https://github.com/bitcoin/bitcoin/issues/33293#issuecomment-3250566706)
Seems we are probably already swapping before we start the functional tests:

https://github.com/willcl-ark/bitcoin/actions/runs/17442003339/job/49527090325#step:8:3768

I tested cleaning scratch dir and object files in this run which got it to pass. They seem the obvious choices to me to remove (probably right after building), any other ideas here?

⚠️ AceHack opened an issue: "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3"
(https://github.com/bitcoin/bitcoin/issues/33298)
This is a significant security issue. I don't want to allow easily decodable images in my transactions because, by law, I would then be responsible for content moderation. Please save Bitcoin for the little guys like me so we can continue to run a node and home miners legally without fear. I hope nothing immoral or illicit that is easily decodable ever makes it into the actual chain, the miner responsible should be immediately arrested who mined that block. I don't want to relay this crap eit
...

💬 ryanofsky commented on issue "cmake: Errors not actually errors?":
(https://github.com/bitcoin/bitcoin/issues/33153#issuecomment-3250597155)
> Since we want to distribute our own packages, we have no way to provide .pc files that are not broken.

This seems like a reason not to distribute .pc files, but it doesn't seem like a reason not to generate them in local builds and generate them for package managers. There are other build systems besides cmake, and it seems like it would be nice if you could build and install the kernel from source or use a package manager, and build against the library in a meson project, or rust/zig/python/
...

📝 mzumsande opened a pull request: "wallet: reduce unconditional logging during load"
(https://github.com/bitcoin/bitcoin/pull/33299)
Currently the unconditional log during init with a default wallet happens three times:
```
2025-09-03T19:57:16Z init message: Verifying wallet(s)…
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
(...)
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z init
...

💬 pinheadmz commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250621739)
v29 and all supported previous versions of Bitcoin allow "easily decodeable images" in transaction data, inscriptions proved that. In fact, stuffing data into witness blobs is *cheaper* than stuffing it in to op_returns. I think this issue should be closed as a duplicate but you can still comment here (or, perhaps more appropriately, on bitcoin.stackexchange.com) if you have additional questions. Please keep in mind the Bitcoin Core issue tracker is reserved for specific implementation issues an
...

✅ achow101 closed an issue: "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3"
(https://github.com/bitcoin/bitcoin/issues/33298)

💬 optout21 commented on pull request "mini miner: enable `Linearize` return package feerates":
(https://github.com/bitcoin/bitcoin/pull/33216#issuecomment-3250624967)
This PR only extends the return data with the package fee rate, but it does not use the new data. Is a follow-up PR available (as draft) where the new data is used?