Matt Corallo

> As I said in https://github.com/bitcoin/bitcoin/issues/31109#issuecomment-2450539742 this seems like an optimization that can wait. Right, and in the next comment I replied with 4 reasons why its relevant, only two...

I was referencing the comment at https://github.com/bitcoin/bitcoin/issues/31109#issuecomment-2450593825 The changes proposed do not accomplish point 1, 3, or 4, only point 2. Point 2 is possible more important than 1 or...

> 1. reduces (tail) latency when requesting a block. In most cases it won't matter, but immediately after finding a new block there is potentially a lot of cs_main contention...

> There's no reason Mining.createNewBlock or BlockTemplate.waitNext methods need to use cs_main. cs_main is an implementation detail and not part of the interface. For example we could have: Sure, my...

I had not, thanks. Fixed.

I'm really quite confused by this. Creating a "template IPC" interface is not substantially different than creating any other protocol for providing templates. What is the advantage for Bitcoin core...

My understanding of the conversation previously was (a) a desire to avoid a ton of TCP logic (which will largely be addressed by upcoming work to remove libevent's HTTP server...

> The mining interface in interfaces/mining.h, node/interfaces.cpp and mining.capnp is orders of magnitude less code than what's currently in https://github.com/Sjors/bitcoin/pull/68. That would be still be true after a refactor of...

Its probably worth pointing out that with new MEV-extraction things coming out these days Bitcoin Core will not be the only server of work, which means we also need to...

> It's literally in https://github.com/Sjors/bitcoin/pull/68, split between https://github.com/Sjors/bitcoin/pull/66, https://github.com/Sjors/bitcoin/pull/67, https://github.com/Sjors/bitcoin/pull/50 and https://github.com/Sjors/bitcoin/pull/49 in that order. I've already refactored that code to use the interface, just not via IPC, so it's...