💬 polespinasa commented on pull request "rpc, logging: add backgroundvalidation to getblockchaininfo":
(https://github.com/bitcoin/bitcoin/pull/33259#discussion_r2349653359)
I don't think that's useful. The test is not much longer than others and `check_tx_counts` is separated in a function because it's called multiple times with different values of `final`. In this case there's no duplicated code.

💬 polespinasa commented on pull request "rpc, logging: add backgroundvalidation to getblockchaininfo":
(https://github.com/bitcoin/bitcoin/pull/33259#issuecomment-3293196760)
21fb4c949cebf3510dad3dc3827ccb9451e4828d correct typos

💬 ryanofsky commented on pull request "test: don't throw from the destructor of DebugLogHelper":
(https://github.com/bitcoin/bitcoin/pull/33388#issuecomment-3293213987)
Cap'n Proto has a policy of declaring destructors `noexcept(false)` and using `std::uncaught_exception()` to prevent throwing more than once under the assumption that "ff another exception is already active, the new exception is assumed to be a side-effect of the main exception, and is either silently swallowed or reported on a side channel." It seems like that could be a reasonable approach here. The DebugLogHelper destructor could continue to throw normally, but just log if another exception w
...

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349670936)
I tried explaining it in
[`6222d8c` (#33336)](https://github.com/bitcoin/bitcoin/pull/33336/commits/6222d8cced4828b83a9dde20b9da9df44848b9bd)
> Instead of true/false or enabled/disabled, the checked/skipped naming should help with understanding when signature verification is actually performed.

But seems it's not a good explanation. I found it confusing to say that we disable assume valid - so are we doing the script checks or not. So what's a better expression to avoid the confusion?

💬 Roasbeef commented on issue "Difficulty in reliably mapping errors from Bitcoin Core due to unstable error codes and messages":
(https://github.com/bitcoin/bitcoin/issues/33350#issuecomment-3293222771)
Ah, I meant `testmempoolaccept`. `testmempoolaccept` was called, but a new/different error was returned, so we weren't able to make a decisions w.r.t "should we retry or is it hosed".

Re atomic transaction submission, what I mean is that a sort of race condition can arise between the time you call `testmempoolaccept`, and when you actually submit the package.

✅ achow101 closed an issue: "v30 Testing (BUG)"
(https://github.com/bitcoin/bitcoin/issues/33393)

🤔 l0rinc reviewed a pull request: "log: always print initial signature verification state"
(https://github.com/bitcoin/bitcoin/pull/33336#pullrequestreview-3225673910)
Thanks for the suggestions, applied most of them

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349705964)
But extracting `TWO_WEEKS_IN_SECONDS` is safe, did that, thanks. Added you as coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349700463)
Done

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349699960)
Changed in latest push, thanks

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349714482)
Lol, valid point, let's document what we *are* doing, not just what we're not :D
Added comment and updated the commit message (but kept the todo for now), added you as coauthor.

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349709237)
the 4th is doing a reindex even in the first commit, right?

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349696433)
Done, thanks, added you as coauthor

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349727088)
Done

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349727601)
Added one above + explained lightly in commit message

💬 l0rinc commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2349693427)
Done, thanks

💬 Rev-9T commented on issue "v30 Testing (BUG)":
(https://github.com/bitcoin/bitcoin/issues/33393#issuecomment-3293334447)
Knots do not have this bug.

💬 ryanofsky commented on issue "RFC: Bitcoin Core Node `BlockTemplateManager`":
(https://github.com/bitcoin/bitcoin/issues/33389#issuecomment-3293358522)
Another link to the POC branch: https://github.com/bitcoin/bitcoin/compare/master...ismaelsadeeq:bitcoin:09-2025-minerman

This seems like a good idea. The actual change here doesn't seem very big and it seems like it could avoid some wasted memory and wasted work. It does seem like `BlockTemplateManager` is currently duplicating some logic in `WaitAndCreateNewBlock`, but I think the idea would be to replace it?

This idea also seems like it might relate to https://github.com/bitcoin/bitcoin/iss
...

💬 l0rinc commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2349768694)
Excellent, added @w0xlt as a coauthor.
I kept `ShouldWarnOversizedDbCache` since this makes it unit-testable.

💬 polespinasa commented on pull request "rpc: print P2WSH and P2SH redem Script in getrawtransaction":
(https://github.com/bitcoin/bitcoin/pull/31252#discussion_r2349780315)
Nice catch!
You're right, solved in 1d156fce6f1634ca796e4e1ecf1763494f7d4fb2.
Now non-P2SH and non-segwit inputs return -2 and don't show any script as it's out the scope of the PR.