🚀 fanquake merged a pull request: "test: re-bucket long-running tests"
(https://github.com/bitcoin/bitcoin/pull/30879)

💬 hebasto commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378944754)
My bad! I downloaded binaries for `x86_64` arch on `arm64` machine. They were using the Rosetta framework.

💬 willcl-ark commented on pull request "docs: Add instructions on how to self-sign bitcoin-core binaries for macOS":
(https://github.com/bitcoin/bitcoin/pull/30982#issuecomment-2378949502)
> I downloaded binaries for `x86_64` arch on `arm64` machine. They were using the Rosetta framework.

A very sneaky undocumented workaround!

🤔 ismaelsadeeq reviewed a pull request: "Cluster linearization: separate tests from tests-of-tests"
(https://github.com/bitcoin/bitcoin/pull/30605#pullrequestreview-2333401196)
Code review ACK 0cae0c487cb8b32b96f888a31e818f2a90f848cc

💬 stickies-v commented on pull request "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error":
(https://github.com/bitcoin/bitcoin/pull/30928#discussion_r1778429402)
I assumed the next step would be to validate the `bilingual_str` overload at compile-time too, but I've been looking at implementing that and with the run-time translation dependency (`QCoreApplication::translate`) it doesn't really seem feasible.

I hadn't considered that translations can introduce format errors too, which makes the case for `bilingual_str` format errors not throwing ever stronger indeed. I was worried that blanket catching all formatting errors at the `tfm` level could be co
...

💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2379013786)
Rebased after #30940

💬 Sjors commented on pull request "rpc: add optional blockhash to waitfornewblock":
(https://github.com/bitcoin/bitcoin/pull/30635#discussion_r1778446846)
So this effects GUI users that use the console, rather than bitcoin-cli?

💬 stickies-v commented on pull request "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error":
(https://github.com/bitcoin/bitcoin/pull/30928#issuecomment-2379043395)
Force-pushed to address @maflcko's [comment](https://github.com/bitcoin/bitcoin/pull/30928/#discussion_r1776965132) about generally not letting `tinyformat` throw format errors, instead of just for the `util::ConstevalFormatString` overloads. Most notably, this changes behaviour for the `bilingual_str` `format` overload to also not throw.

👍 maflcko approved a pull request: "tinyformat: refactor: increase compile-time checks and don't throw for tfm::format_error"
(https://github.com/bitcoin/bitcoin/pull/30928#pullrequestreview-2333489859)
lgtm

💬 hebasto commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2379073216)
> I like the idea of a unified `bitcoin` command.

So do I.

Would it be beneficial for users if we started shipping DEB and RPM packages? The package manager would handle the proper installation of multiple executables.

💬 Sjors commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#issuecomment-2379079961)
Nice! I'll try to use this for `Sv2Connman` in https://github.com/Sjors/bitcoin/pull/50 and will let you know if anything is missing.

Can you put `sockman.h` in `libbitcoin_common` instead of `libbitcoin_node`? For the Template Provider I'm trying to prevent a circular dependency on the node. I think this can be done by moving a few more things out of net.h. This should do the trick: https://github.com/bitcoin/bitcoin/commit/4dd51b2924860bf10466da080ea4ff7bed1a3e3f

👋 brunoerg's pull request is ready for review: "p2p: rpc: add `tx_reconciliation` to `getpeerinfo`"
(https://github.com/bitcoin/bitcoin/pull/30984)

💬 antonilol commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-2379086150)
How hard is it for attackers to deliberately insert collisions? Is it worth to (try to) counteract this?

💬 maflcko commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1778257807)
nit: Arrays are sorted and I don't think it is user-friendly to shuffle them by ID. I think this comment can just be removed.

💬 maflcko commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2379102811)
> Would it be beneficial for users if we started shipping DEB and RPM packages? The package manager would handle the proper installation of multiple executables.

IIRC there were some in the packagin repo, but they were both removed due to being unmaintained, see https://github.com/bitcoin-core/packaging?tab=readme-ov-file#bitcoin-core-packaging

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-2379167604)
> How hard is it for attackers to deliberately insert collisions? Is it worth to (try to) counteract this?

The index is currently based on suggestions by @hodlinator and @antonilol and the key for a given outpoint is the last 8 bytes of the outpoint's tx hash, represented as an 8 bytes integer, to which we add the outpoint's output index.
=> to generated collisions attackers need to generate transactions which hash to values that have the same first 8 bytes. I guess that would not be that d
...

💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-2379174442)
Another option that I'm looking at is simply to replace and extend `txindex` and create 2 indexes:

- txid (32 bytes) -> tx position (8 bytes) (same as txindex)
- tx position (8 bytes) + output index (4 bytes) -> spending tx position (8 bytes)

No more collisions, and we can return the full tx and not just its hash, but not as efficient as this version (which can also return the full tx)l

💬 maflcko commented on issue "win64-cross CI timeout after 2h ":
(https://github.com/bitcoin/bitcoin/issues/30969#issuecomment-2379179384)
It is just 2 hours of nothing (no logs, etc):

```
[10:48:14.556] 135/136 Test #1: util_test_runner ..................... Passed 550.41 sec
[12:17:58.568]
[12:17:58.568] Timed out!
```

https://cirrus-ci.com/task/5511579989442560?logs=ci#L2605

💬 maflcko commented on pull request "fuzz: fuzz connman with non-empty addrman + ASMap":
(https://github.com/bitcoin/bitcoin/pull/29536#issuecomment-2379194976)
review ACK 552cae243a1bf26bfec03eccd1458f3bf33e01dc 🏀

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK 552cae243a1b
...

💬 ryanofsky commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2379204971)
re: https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2378828326

> We could start with seperate binaries for multiprocess, e.g.:

This makes sense. Initially I was thinking all the binaries had to live in the same place, but this is not true. We could leave all existing binaries where they are in `bin/` and just add 3 new files to releases when multiprocess option is turned on:

- `bin/bitcoin`
- `libexec/bitcoin-node`
- `libexec/bitcoin-gui`

Implementing this might be as
...