💬 ryanofsky commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2940549074)
re: https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2939117270

> Now that #31375 landed, can you add `bitcoin mine` as a command?

Oops, somehow i thought I had already done that..

Added 1 commit 27c6576aba5c59402b8844703e04face2f41578c -> 278101f6ee723e6401ddb3e46f2fce3b60cc42ca ([`pr/mine.24`](https://github.com/ryanofsky/bitcoin/commits/pr/mine.24) -> [`pr/mine.25`](https://github.com/ryanofsky/bitcoin/commits/pr/mine.25), [compare](https://github.com/ryanofsky/bitcoin/comp
...

💬 pinheadmz commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2126939031)
I don't think that's possible, the two RPCs are `getblockcount` and `waitforblockheight`, those two responses together including their HTTP overhead only total about 500 bytes so I don't think `recv(1024)` would truncate anything. If the server is extremely slow the client may even have to call `recv()` twice in the while loop, reading only about 250 bytes each time.

💬 pinheadmz commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2126941493)
Good call thanks. I will do this if I retouch this PR, otherwise will add to #32061 on rebase

💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2126952270)
> allow duplicate keys or more thorowly prevent them.

Yes, I've suggest to the [mailing list](https://groups.google.com/g/bitcoindev/c/SSpyvbD9CMg) that we should allow the duplicate keys. Still checking with cryptographers that that will be okay, particularly since PSBT doesn't allow duplicate participants to use different pubnonces and partial sigs.

🤔 hebasto reviewed a pull request: "guix: warn and abort when SOURCE_DATE_EPOCH is set"
(https://github.com/bitcoin/bitcoin/pull/32678#pullrequestreview-2897373309)
My Guix build:
```
aarch64
13c339d8340af9456ad236a76bdd7faaed0f694849e6ad15da328d17d0c87ede guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/SHA256SUMS.part
afc24aab271148828178b89379a4e518664415163601c7628e93d9cf53616314 guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/bitcoin-5c4a0f8009ce-aarch64-linux-gnu-debug.tar.gz
7bba24165e6924ec1acddb0cc4e29c708dbb1b98f2e30405d06668f1d16c71ff guix-build-5c4a0f8009ce/output/aarch64-linux-gnu/bitcoin-5c4a0f8009ce-aarch64-linux-gnu.tar.gz
0be9eb9a
...

💬 Christewart commented on pull request "[Policy] Discourage Unsigned Annexes":
(https://github.com/bitcoin/bitcoin/pull/32453#issuecomment-2940670379)
Concept ACK

>existing annex discouragement.

Could you link to these?

Else tests would be nice.

💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2940776051)
> 1) & 2)

`MAX_BLOCK_DB_CACHE` sets `block_cache` which is used to configure `leveldb::Options.block_cache` and `.write_buffer_size`. It's not strictly related to `max_file_size` - see https://github.com/bitcoin/bitcoin/blob/master/src/leveldb/db/db_impl.cc#L104-L105.

> 2 MiB is a clear winner

@andrewtoth just had a brilliant realization that I hadn't thought of: you've just switched to v29, so you will still need to convert your 2 MiB files to 32 MiB files which requires heavy compaction at
...

💬 Sjors commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#issuecomment-2940777552)
ACK 278101f6ee723e6401ddb3e46f2fce3b60cc42ca

📝 ismaelsadeeq opened a pull request: "doc: update tor docs to use correct bitcoind binary path"
(https://github.com/bitcoin/bitcoin/pull/32679)
I noticed this while trying to run a node over Tor.
Using `./bitcoind` as the executable path is incorrect.

It should be `./build/bin/bitcoind`.

This is a simple documentation update PR that fixes the path.

💬 davidgumberg commented on pull request "doc: update tor docs to use correct bitcoind binary path":
(https://github.com/bitcoin/bitcoin/pull/32679#issuecomment-2940798550)
ACK https://github.com/bitcoin/bitcoin/pull/32679/commits/b42ba6f806cda1e771ca9a0d57cc9716d1110a04

💬 andrewtoth commented on pull request "doc: update tor docs to use correct bitcoind binary path":
(https://github.com/bitcoin/bitcoin/pull/32679#issuecomment-2940816392)
The docs do not assume you are building bitcoind from source. They are assuming you are running the commands from whichever directory bitcoind is in.

👍 hebasto approved a pull request: "doc: update tor docs to use correct bitcoind binary path"
(https://github.com/bitcoin/bitcoin/pull/32679#pullrequestreview-2897531979)
ACK b42ba6f806cda1e771ca9a0d57cc9716d1110a04.

Backport to 29.x?

💬 ismaelsadeeq commented on pull request "doc: update tor docs to use correct bitcoind binary path":
(https://github.com/bitcoin/bitcoin/pull/32679#issuecomment-2940838822)
> They are assuming you're running the commands from whatever directory `bitcoind` is in.

I dont think that's what it is assuming by explicitly indicates that the binary is in the current directory, which isn't true.
Yes, you could argue that the `build` in the new docs path is just a default and users can change it, but `bin/bitcoind` is constant. So we're just updating the docs to reflect the default setup.

> The docs do not assume you're building `bitcoind` from source.

If that wer
...

💬 l0rinc commented on pull request "fuzz: Add target for coins database":
(https://github.com/bitcoin/bitcoin/pull/32602#issuecomment-2940862921)
code review ACK cfc42ae5b7ef6d3892907cfe36dc3ae923495d37

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2127121713)
this is gone now

🤔 Crypt-iQ reviewed a pull request: "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError"
(https://github.com/bitcoin/bitcoin/pull/32604#pullrequestreview-2897579695)
The latest change uses a single `BCLog::LogRateLimiter` instance and uses a slimmer way of tracking the amount of logging bytes left per `std::source_location`. I like the approach better as `m_categories` is no longer being used. I would like to point out that the rate-limiting logic can be bypassed if `LogPrintLevel` is used. I think `LogPrintLevel` callers need to be cautious and I kind of think this macro shouldn't be used if `level >= BCLog::Level::Info`.

> Will that appear on the consol
...

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2127118833)
Implemented this change, lmk what you think. I think this encapsulates code a bit better, but it probably could still be improved.

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2127117379)
I want to address this because I think it would be useful to catch in debug builds via `Assume` but also don't want to break tests. Do you think this should be addressed?

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2127126139)
I've changed this so that the logging macros eventually pass a `should_ratelimit` bool to `LogPrintStr`. Instead of introducing a new macro for `UpdateTipLog`, it now uses `LogPrintLevel` which can bypass the rate-limiting. I'm not sure how I feel about using `LogPrintLevel` as I don't want to encourage more usage of it in the codebase as it could be a potential footgun.

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2127134262)
Resolving as I've removed categories.