💬 fuleru commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2418275162)
It’s a bit scary. Currently, testnet4 block generation is controlled. https://mempool.space/testnet4/address/tb1q2dsc94zq40nwnz27w5rxljwllutnwjtlxk44fz

🤔 glitteryskye99 reviewed a pull request: "doc: update signet documentation related to build directories"
(https://github.com/bitcoin/bitcoin/pull/30996#pullrequestreview-2374014243)
Interesting

🤔 ariard reviewed a pull request: "validation: Improve input script check error reporting"
(https://github.com/bitcoin/bitcoin/pull/31097#pullrequestreview-2374018383)
Re-tested, getting the correct RPC string.

💬 ariard commented on pull request "validation: Improve input script check error reporting":
(https://github.com/bitcoin/bitcoin/pull/31097#discussion_r1804025893)
```
diff --git a/src/validation.cpp b/src/validation.cpp
index fc61b14dc1..ecc1ab22dd 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -1970,7 +1970,7 @@ bool CheckInputScripts(const CTransaction& tx, TxValidationState& state,
CScriptCheck check2(txdata.m_spent_outputs[i], tx, i,
flags & ~STANDARD_NOT_MANDATORY_VERIFY_FLAGS, cacheSigStore, &txdata);
if (check2())
- return state.Invalid(TxValidationR
...

💬 l0rinc commented on pull request "memusage: let PoolResource keep track of all allocated/deallocated memory":
(https://github.com/bitcoin/bitcoin/pull/28939#issuecomment-2418832550)
@martinus are you still working on this or should we review the cherry-picked changes in https://github.com/bitcoin/bitcoin/pull/31102 instead?

👍 laanwj approved a pull request: "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues"
(https://github.com/bitcoin/bitcoin/pull/30349#pullrequestreview-2374468113)
ACK c49cc30b8185a50b4aa00cf705d313c8aa9482a3

💬 martinus commented on pull request "memusage: let PoolResource keep track of all allocated/deallocated memory":
(https://github.com/bitcoin/bitcoin/pull/28939#issuecomment-2418867904)
Hi @l0rinc, sorry I most likely can't work on this or anything else in the forseeable future

✅ fanquake closed a pull request: "memusage: let PoolResource keep track of all allocated/deallocated memory"
(https://github.com/bitcoin/bitcoin/pull/28939)

💬 l0rinc commented on pull request "memusage: let PoolResource keep track of all allocated/deallocated memory":
(https://github.com/bitcoin/bitcoin/pull/28939#issuecomment-2418877072)
Thanks for the quick response, @andrewtoth cherry-picked your changes and we'll continue there

✅ fanquake closed an issue: "doc: Fixup windows-cross build notes"
(https://github.com/bitcoin/bitcoin/issues/31090)

🚀 fanquake merged a pull request: "doc: remove dependency install instructions from win docs"
(https://github.com/bitcoin/bitcoin/pull/31100)

👍 laanwj approved a pull request: "doc: remove dependency install instructions from win docs"
(https://github.com/bitcoin/bitcoin/pull/31100#pullrequestreview-2374503030)
ACK 184f12c1542f6c53eb2bd9dfb08dfdd490e38846
i agree this is the better way to handle documentation, have as little redundancy as possible.
Also always found the reference to `build-windows.md` from the depends `README.md ` kind of surprising, so i'm glad it's removed.

🤔 murchandamus reviewed a pull request: "Bugfix: Correct first-run free space checks"
(https://github.com/bitcoin/bitcoin/pull/29678#pullrequestreview-2374521609)
All of these changes seem consistent to me.

Concept ACK on generally using GB to refer to 1,000,000,000 bytes and GiB to refer to 1024³ bytes everywhere.

💬 Sjors commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-2418903448)
> I'm curious where the bulk of that is.

It's literally in #68, split between #66, #67, #50 and #49 in that order. I've already refactor that code to use the interface, just not via IPC, so it's _all_ additional.

> framing and such all has to happen either way, even if its auto-generated code when using capnproto

I think you misunderstand the intended setup: the idea is to have a `bitcoin-node` application to which you connect via unix socket a `bitcoin-stratum` Template Provider applic
...

💬 hebasto commented on issue "Building libsecp256k1 fails on OpenBSD 7.6":
(https://github.com/bitcoin/bitcoin/issues/31106#issuecomment-2418906698)
> ### Expected behaviour
>
> A successful build of a libsecp256k1 is possible by strictly following the instructions found within `src/secp256k1/README.md`.

I think you should move this issue upstream to https://github.com/bitcoin-core/secp256k1/issues.

💬 hebasto commented on issue "Building libsecp256k1 fails on OpenBSD 7.6":
(https://github.com/bitcoin/bitcoin/issues/31106#issuecomment-2418916727)
Also try:
```
pkg_add libtool
```

✅ fanquake closed an issue: "Building libsecp256k1 fails on OpenBSD 7.6"
(https://github.com/bitcoin/bitcoin/issues/31106)

💬 fanquake commented on issue "Building libsecp256k1 fails on OpenBSD 7.6":
(https://github.com/bitcoin/bitcoin/issues/31106#issuecomment-2418928156)
Yes, please move this upstream. Building libsecp standalone isn't supported inside this repository.

💬 laanwj commented on issue "Distribute darknet node addresses via DNS seeds using AAAA records":
(https://github.com/bitcoin/bitcoin/issues/31062#issuecomment-2418932066)
Concept NACK

It's a clever trick, but we've considered this kind of thing before and it's a really a deep rabbit hole.

From what i heard it's not generally a good idea to stash different data in AAAA records. Caching DNS servers can have checks to assume the addresses are routable and valid. Additionally, there's also no guarantee that clients get all the addresses, so splitting the data is a bit brittle.

This would also break the assumption that a random address returned from the DNS s
...

💬 laanwj commented on pull request "RFC: build: support for pre-compiled headers.":
(https://github.com/bitcoin/bitcoin/pull/31053#issuecomment-2418937798)
Concept ACK. It's nice that CMAKE proves a built-in abstraction for this so there's no need for really ugly stuff.