💬 ajtowns commented on pull request "ArgsManager: support subcommand-specific options":
(https://github.com/bitcoin/bitcoin/pull/28802#discussion_r2536361107)
Not currently, I think

💬 ajtowns commented on pull request "ArgsManager: support subcommand-specific options":
(https://github.com/bitcoin/bitcoin/pull/28802#discussion_r2536364679)
Added some unit test coverage

💬 ajtowns commented on pull request "ArgsManager: support subcommand-specific options":
(https://github.com/bitcoin/bitcoin/pull/28802#issuecomment-3545163344)
> If you can, I would appreciate adding slightly more context to the PR description and the commit messages.

Sorry, these seem completely self-explanatory to me, so I don't see what to add. Happy to answer questions or take suggestions though.

💬 ajtowns commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3545336207)
> Unless we overhaul the sv2 [NewTemplate message](https://stratumprotocol.org/specification/07-Template-Distribution-Protocol/#72-newtemplate-server-client) it doesn't help

Yes, I'm saying I think `NewTemplate` (and `CoinbaseOutputConstraints`) should be overhauled, to avoid sv2 software generating or modifying the coinbase, beyond adjusting the values in a reserved extranonce area of known/fixed size. (Parsing the coinbase tx is still necessary for the pool to determine whether to accept a
...

💬 yuvicc commented on pull request "kernel: Expose reusable `PrecomputedTransactionData` in script validation":
(https://github.com/bitcoin/bitcoin/pull/33891#issuecomment-3545630672)
Concept ACK

[Wrote](https://github.com/yuvicc/test-bitcoinkernel/blob/master/context_free.c) a small program to test `btck_PrecomputedTransactionData`.

✅ maflcko closed a pull request: "precalculate SipHash constant salt XORs"
(https://github.com/bitcoin/bitcoin/pull/30442)

📝 maflcko reopened a pull request: "precalculate SipHash constant salt XORs"
(https://github.com/bitcoin/bitcoin/pull/30442)
This change is part of [[IBD] - Tracking PR for speeding up Initial Block Download](https://github.com/bitcoin/bitcoin/pull/32043)

### Summary

The in-memory representation of the UTXO set uses (salted) [SipHash](https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L226) for avoiding key collision attacks.

Hashing `uint256` keys is performed frequently throughout the codebase. Previously, specialized optimizations existed as standalone functions (`SipHashUint256` and `SipHashUint25
...

📝 maflcko opened a pull request: "clang-format: Set InsertNewlineAtEOF: true"
(https://github.com/bitcoin/bitcoin/pull/33896)
Now that the minimum supported clang version is 17, the `InsertNewlineAtEOF` setting can be set to `true` in the clang-format file. (https://releases.llvm.org/16.0.0/tools/clang/docs/ClangFormatStyleOptions.html#insertnewlineateof)

This is in line with the already existing newline linter. Can be tested via:

```
truncate -s -1 src/init.cpp
git diff

# Should fail:
cargo run --manifest-path ./test/lint/test_runner/Cargo.toml -- --lint=trailing_newline

# Restore newline:
git diff -U0
...

💬 optout21 commented on pull request "refactor: remove incorrect lifetimebounds":
(https://github.com/bitcoin/bitcoin/pull/33870#discussion_r2536712096)
Yes, a similar check could be done in the beginning, when `tip` is retrieved. But prob. outside of the scope of this PR.

💬 maflcko commented on pull request "guix: update per-host disk-space estimates in build gate":
(https://github.com/bitcoin/bitcoin/pull/33889#discussion_r2536789722)
> I did notice discrepancies for darwin and mingw though, which I've attempted to correct for.

That is fine, but you'll have to properly explain the changes.

https://github.com/kevkevinpal/bitcoin/issues/200 could be an oversight where someone ran the build twice by accident?

💬 maflcko commented on pull request "test, refactor: Embedded ASMap [1/3]: Selected minor preparatory work":
(https://github.com/bitcoin/bitcoin/pull/33026#discussion_r2536798319)
The call should be fully optimized out anyway, no?

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3546154209)
> OTOH, overhauling NewTemplate shouldn't be a blocker for supporting sv2 efficiently, so Approach ACK for this PR in the meantime.

Thanks, I opened https://github.com/stratum-mining/sv2-spec/issues/167 to continue that discussion.

>> replacing m_options.coinbase_output_script with a vector.

See https://github.com/bitcoin/bitcoin/pull/33890

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2536880741)
Done in the latest push.

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3546216186)
I slightly simplified `ExtractCoinbaseTemplate` by having it assume that the dummy is always the first output. Also TIL about `| std::views::drop(1)`.

💬 janb84 commented on pull request "guix: update per-host disk-space estimates in build gate":
(https://github.com/bitcoin/bitcoin/pull/33889#discussion_r2536950754)
It was my remark, and I was still researching it. My Guix build is using GiB than before, but it's not related to 33181. I noticed it on that PR but a master compile (sans 33181) was also consuming more space than before.

💬 fanquake commented on pull request "depends: update xcb-util packages to latest versions":
(https://github.com/bitcoin/bitcoin/pull/33851#issuecomment-3546351254)
Guix Build (x86_64):
```bash
3a70d632167f9e57328d9b8373a5eb9936428148feddf5bc1f9834f412ea4248 guix-build-daafaef87fee/output/aarch64-linux-gnu/SHA256SUMS.part
ca1c7ad00632d0ee3fdfad498a7c6cb5246240a9e49c89bee508355ee7dbb832 guix-build-daafaef87fee/output/aarch64-linux-gnu/bitcoin-daafaef87fee-aarch64-linux-gnu-debug.tar.gz
a5a5c5a22159a912f573915727b5a4cdbb1b270fdf099f8b465c3ef940496e20 guix-build-daafaef87fee/output/aarch64-linux-gnu/bitcoin-daafaef87fee-aarch64-linux-gnu.tar.gz
a660c55
...

💬 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-3546355023)
> It builds fine for me on an instance from the same provider:

Okay, now i'm confused. What operating system? Also debian forky/sid?

It could be that they got me a faulty server? i can't imagine having done anything wrong here, just followed basic GUIX build steps.

💬 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-3546364000)
Looks like it stopped an error in the `-rust-1.65.0.drv.gz` build this night. The "faulty server" hypothesis definitely disproven 😄 Why do i always have this little luck with RISC-V devices lol.
```
...
patch-cargo-checksums: generate-checksums for vendor/winapi
patch-cargo-checksums: generate-checksums for vendor/windows-sys-0.28.0
patch-cargo-checksums: generate-checksums for vendor/windows-sys
patch-cargo-checksums: generate-checksums for vendor/windows_aarch64_msvc-0.28.0
Fatal glibc error
...

🚀 fanquake merged a pull request: "net: Remove unused `local_socket_bytes` variable in `CConnman::GetAddresses()`"
(https://github.com/bitcoin/bitcoin/pull/33894)

💬 hodlinator commented on pull request "build: Embedded ASMap [3/3]: Build binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#discussion_r2537150160)
Related: #33896