💬 roconnor-blockstream commented on issue "Standardness policy rules for legacy Multisig script is incoherent":
(https://github.com/bitcoin/bitcoin/issues/33882#issuecomment-3542129055)
> The requirement is for m not to be greater than n, as far as I can see? (via both IsStandard() and Solver())

Yeah, I meant to say "less than or equal to". However, AFAICT this inequality is only enforced in standardness, not solvability.

💬 laanwj commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3542166449)
Right! i could take a look at fixing this upstream.

From a high level perspective, i don't quite understand why a cpuinfo module would be needed for deterministic cross-compiling in the first place. Nor why it'd run tests that depend on local CPU configuration. But i guess it's some deeper nested dependency that gets pulled in unconditionally (through LIEF in this case?). GUIX sadly has more of those, basically same complaint as in #30042.

💬 fanquake commented on pull request "ci: Enable experimental kernel stuff in most CI tasks via `dev-mode`":
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2534330486)
Any idea why `BUILD_GUI_TESTS=OFF` was previously set? Looks like it predates CMake, and was just ported; I guess no-longer needed?

💬 maflcko commented on issue "upstream: GUIX closure contains too much unnecessary stuff":
(https://github.com/bitcoin/bitcoin/issues/30042#issuecomment-3542213579)
The linked issue is now closed with the last comment:

> With commit 9fa92acbf0c4dbc734ac7d83b31bd6d12e09a401 (https://codeberg.org/guix/guix/commit/9fa92acbf0c4dbc734ac7d83b31bd6d12e09a401) this is mostly
fixed. There’s still another path leading to libx11 though:

```
$ ./pre-inst-env guix graph --path guix libx11
guix@1.4.0-6.dc5430c
guile-avahi@0.4.1
avahi@0.8
dbus@1.14.0
libx11@1.8.1

(The same applies to “guix pull”.)

Not sure what can be done about it.

Ludo’.

💬 maflcko commented on issue "guix build fails on RISC-V due to python-py-cpuinfo test failure":
(https://github.com/bitcoin/bitcoin/issues/33873#issuecomment-3542218159)
Yeah, if it is pulled in through LIEF, it could make sense to strip the unmaintained dependency from LIEF upstream.

💬 maflcko commented on pull request "ci: Enable experimental kernel stuff in most CI tasks via `dev-mode`":
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2534374440)
I think it couldn't be run in wine. Could make sense to at least build it. Should I do it here, or in a follow-up?

💬 maflcko commented on pull request "ci: Enable experimental kernel stuff in most CI tasks via `dev-mode`":
(https://github.com/bitcoin/bitcoin/pull/33824#discussion_r2534381180)
oh wait, I already removed it here in this commit 6666980e8653d98ef556f71a3e6907d3deda7147, it is also mentioned in the commit message.

💬 fanquake commented on pull request "depends: update xcb-util packages to latest versions":
(https://github.com/bitcoin/bitcoin/pull/33851#issuecomment-3542279628)
Guix Build:
```bash
70818d2b6cce3f70f1b558049b7d24e3e0d688b51b9ec4257f9e21b4167b1753 guix-build-7d2352b6757e/output/aarch64-linux-gnu/SHA256SUMS.part
fe7f75313ba0ad242e42b2fec0918d4ed21b5b466fc9c373b16496151a6bbe96 guix-build-7d2352b6757e/output/aarch64-linux-gnu/bitcoin-7d2352b6757e-aarch64-linux-gnu-debug.tar.gz
4e3226f11a59d5d417d03296a8defbc43fc169b5eb625a3f234fa4edfb5df303 guix-build-7d2352b6757e/output/aarch64-linux-gnu/bitcoin-7d2352b6757e-aarch64-linux-gnu.tar.gz
9809d8794969a4a7
...

💬 roconnor-blockstream commented on issue "Standardness policy rules for legacy Multisig script is incoherent":
(https://github.com/bitcoin/bitcoin/issues/33882#issuecomment-3542353380)
> we should make it easy to spend bare multisigs with embedded data, or with hybrid pubkeys

Just to be clear, we cannot allow hybrid pubkeys to be processed by `CHECKMULTISIG` without undermining the purpose of the hybrid pubkey ban. (However we can allow hybrid pubkeys that are unprocessed by `CHECKMULTISIG`.)

My understanding of the hybrid pubkey ban is that it is in place in case we wish to, one day, introduce a soft-fork that would allow implementations of Bitcoin Core to use a normal ECD
...

💬 hodlinator commented on pull request "doc: Improve CI docs on env and qemu-user-static":
(https://github.com/bitcoin/bitcoin/pull/33887#discussion_r2534494637)
Thanks! Pushed new version which is hopefully slightly more accurate.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534425987)
renamed.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534443997)
Done.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534465728)
we would probably still need the context string to differentiate between the initial `BlockWorkers()` calls vs the final result `WaitFor`. Should re-check if `BOOST_REQUIRE` prints the stack trace; most likely it doesn't and that was the reason behind my past-self added the context string.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534438190)
I'm not sure about including extra dependencies on a low-level class for tiny readability improvements. But I'm not really opposed to this one, so done as suggested.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534442998)
Done as suggested.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534447295)
Done as suggested.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534473189)
Instead of doing it for all the test cases, added another case that exercises the contention.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534474010)
Done as suggested.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534476766)
Done as suggested.

💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2534496697)
> do we need a vector here of can we just consume whatever we just submitted?

Consuming right away would wait for the task to be executed; we want to exercise some concurrency too.