💬 Sjors commented on pull request "test: clarify timewarp grace period griefing attack":
(https://github.com/bitcoin/bitcoin/pull/31725#issuecomment-3607255055)
[BIP54](https://github.com/bitcoin/bips/blob/master/bip-0054.md) has been updated to use a 2 hour grace period rather than the `MAX_TIMEWARP = 600;` that we use.

If you change `MAX_TIMEWARP` to `7200` there's no way to make the test in this PR pass. I'll leave that as an exercise to the reader.

Note that the list of three bullet items boils down to _a single mistake_: using wall time for `nTime`. And as documented in the Delving post, that's not a hypothetical mistake. It's no longer a pro
...

💬 furszy commented on pull request "wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain)":
(https://github.com/bitcoin/bitcoin/pull/33186#issuecomment-3607270186)
Concept ACK, will review soon

🤔 furszy reviewed a pull request: "qa: Avoid knock-on exception in assert_start_raises_init_error"
(https://github.com/bitcoin/bitcoin/pull/32929#pullrequestreview-3535491080)
Concept ACK, cool stuff

💬 pablomartin4btc commented on pull request "Update about logo icon (colour) to denote the chain type of the QT instance in About/ Help Message Window/ Dialog":
(https://github.com/bitcoin-core/gui/pull/762#issuecomment-3607354974)
_<ins>Updates:</ins>_
- Addressed @laanwj's feedback.
- Reworked the [error message window inconsistency](https://github.com/bitcoin-core/gui/pull/762#issuecomment-2276259183) fix detected by @hebasto [above](https://github.com/bitcoin-core/gui/pull/762#pullrequestreview-2219281894), applying it to most `QMessageBox` possible instances in `bitcoin.cpp` and separating it in the 2nd commit for clarity and in case it needs to be dropped because it's getting out of scope or extended to other files
...

💬 hebasto commented on pull request "depends: Propagate native C compiler to `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3607392698)
My Guiz build:
```
x86_64
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu.tar.gz
fe143b6be
...

✅ hebasto closed a pull request: "depends, doc: Add `tcl` as build dependency for `sqlite` package"
(https://github.com/bitcoin/bitcoin/pull/33975)

💬 hebasto commented on pull request "depends, doc: Add `tcl` as build dependency for `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33975#issuecomment-3607395504)
> > Can we just pass the compiler through?
>
> See #33995.

Closing in favour of https://github.com/bitcoin/bitcoin/pull/33995.

💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3607424994)
Rebased to resolve a conflict with merged bitcoin/bitcoin#33857.

💬 hebasto commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607449106)
Rebased on top of the merged bitcoin/bitcoin#33857.

💬 ryanofsky commented on issue "Memory leak when using IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3607454869)
> yes, that's also my understanding... the puzzling thing is that we're still having the memory leaks... so we're either missing some detail on this analysis, or the cause is related to something other than templates

I think at this point we've ruled out the obvious possible causes of leaks, and need to start debugging the issue more directly.

It would help to have some steps to reproduce. If someone can let me know what code to check out and build, and what commands to run that will show the
...

💬 JeremyRubin commented on pull request "ci: remove `doc/release-notes.md` from lint-spelling.py":
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607478808)
I guess it's _not_ a failure, as it only pops up when other issues flag, but it does get reported in CI as:

```
^---- ⚠️ Failure generated from lint-tests.py
doc/release-notes.md:379: Atack ==> Attack
```

which is sort of confusing

💬 fanquake commented on issue "build: use UCRT runtime for Windows (release) binaries":
(https://github.com/bitcoin/bitcoin/issues/30210#issuecomment-3607488174)
> Since https://github.com/bitcoin/bitcoin/pull/33764 has been merged, this checkbox can now be ticked.

As I mentioned in that PR, neither the headers, neither the compiler version, or headers used, match Guix, so its not exactly testing something similar to how we build releases. That will be improved by #33775.

💬 fanquake commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607495972)
Given it's dropping the other CI, I think this PR should be completing #30210, dropping workarounds, updating any docs, and completing the migration.

💬 maflcko commented on pull request "ci: remove `doc/release-notes.md` from lint-spelling.py":
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607571201)
That could be fixed by rewording, or changing the spacing, maybe something like:

```diff
diff --git a/test/lint/test_runner/src/main.rs b/test/lint/test_runner/src/main.rs
index 5c65fcad89..39ae9dc815 100644
--- a/test/lint/test_runner/src/main.rs
+++ b/test/lint/test_runner/src/main.rs
@@ -742,7 +742,7 @@ fn run_all_python_linters() -> LintResult {
.success()
{
good = false;
- println!("^---- ⚠️ Failure generated from {entry_fn}");

...

💬 ryanofsky commented on issue "should concurrent IPC requests directed to the same thread cause a crash?":
(https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3607727965)
re: https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3566852691

> my main question is whether there are there protection mechanisms in place in case we try to create too many threads at once?

There aren't any currently, and making a lot of threads is probably the easiest way an IPC client could DoS the node.

It wouldn't be hard to create a limit though, if there is a use-case.

I do think creating 5 threads for each client that needs to receive templates sounds like overkill, and
...

👍 sedited approved a pull request: "validation: Improve warnings in case of chain corruption"
(https://github.com/bitcoin/bitcoin/pull/33553#pullrequestreview-3535952294)
ACK 4b4711369880369729893ba7baef11ba2a36cf4b

💬 maflcko commented on pull request "refactor: replace manual promise with SyncWithValidationInterfaceQueue":
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2585968902)
@ANtutov are you still working on this?

👍 ryanofsky approved a pull request: "mining: getCoinbase() returns struct instead of raw tx"
(https://github.com/bitcoin/bitcoin/pull/33819#pullrequestreview-3536150722)
Code review ACK 60f74dd315811db427797a606f4b5611a8c59993. New comments and renaming both seem great, and it is nice to get rid of the extract function. PR feels much more straightforward now.

💬 ryanofsky commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2586011866)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)

Would be nice to avoid the move and treat `pblock` and `coinbase_tx_template` local variables more consistently. Would suggest defining `CoinbaseTxTemplate& coinbase_tx_template{pblocktemplate->m_coinbase_tx_template}` above similar to `pblock`.

💬 ryanofsky commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2585999526)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)

Maybe good to assert witness_index is between 0 and the vout size. Obviously it should be, but good to check array bounds since the index is coming from a different place.