After much discussion in #29432 it appears there's currently little support for directly supporting Stratum v2 in Bitcoin Core, with most contributors favouring the creation of a Mining IPC interface that external applications can use.

The only such application currently is the Template Provider implemented by me in Sjors#48. This also serves to illustrate how the interface is used and that it's complete. The folks working on SRI should be able to build a Template Provider as well, once the interface is complete and shipped in a release.

Needed for (hopefully) v30

To complete the interface:

• Drop script_pub_key arg from createNewBlock #31318
• Add waitNext() to BlockTemplate interface #31283 (replaces Add waitFeesChanged() to Mining interface #31003)
  • Make m_tip_block std::optional #31325
  • test: have miner_tests use Mining interface #31581
• Have createNewBlock() wait for tip, make rpc handle shutdown during long poll and wait methods #31785
• Set notifications m_tip_block in LoadChainTip() #31346
• Prune mining interface #31196
• refactor: mining interface 30955 followups #31197
• Add destroy to BlockTemplate schema #31288
• Possible crash when (not) writing the compact size of the script/prevector bitcoin-core/libmultiprocess#122 (not used by Stratum v2)

Misc bug fixes:

• miner: drop dummy extraNonce in coinbase scriptSig for templates requested via IPC #32420

For multiprocess release binaries

• Add bitcoin-{node,gui} to release binaries for IPC #31802
• Pass custom DEP_OPTS and CONFIG_FLAGS to guix-build #31763 (pending "officially" shipping bitcoin-node)
• multiprocess: Add bitcoin wrapper executable #31375
  • To resolve RFC: Multiprocess binaries and packaging options #30983
• multiprocess: Add libmultiprocess git subtree #31741
• ci: build multiprocess on most jobs #30975
• cmake: Avoid fuzzer "multiple definition of `main'" errors #31992
• cmake: avoid libatomic not found error on debian bitcoin-core/libmultiprocess#119
• Build fails on Bitcoin Core macOS native CI bitcoin-core/libmultiprocess#117
• multiprocess: build failure on Alpine with depends & DEBUG=1 #31455
• ci: intermittent issue in rpc_misc.py node0 stderr terminate called after throwing an instance of 'kj::ExceptionImpl' [15:12:14.943] what(): mp/proxy.cpp:242: disconnected: write(m_post_fd, &buffer, 1): Broken pipe #31151
• bitcoin-node segfaults when interrupted bitcoin-core/libmultiprocess#123
• Bitcoin Core rpc_misc.py test failure bitcoin-core/libmultiprocess#128

Libmultiprocess bugfixes

• proxy-types.h: add static_assert to detect int/enum size mismatch bitcoin-core/libmultiprocess#120
• ProxyClientBase: avoid static_cast to partially constructed object bitcoin-core/libmultiprocess#121
• ProxyClientBase: avoid static_cast to partially destructed object bitcoin-core/libmultiprocess#127

Can wait for later releases

• Rename bitcoin-wallet? #31827
• Windows support
  • windows build failure bitcoin-core/libmultiprocess#114
  • add bitcoin-node.exe etc to Windows build
  • add bitcoin.exe to Windows build (e.g. 26d3a06)
• ipc: add bitcoin-mine test program #30437
• rfc: DATUM mining interface requirements #31002 DATUM developers are currently uninterested in taking advantage of the more performant interface, preferring to use the getblocktemplate RPC instead, despite an earlier concept ACK on Stratum v2 support [WIP] add a stratum v2 template provider #27854 (comment).
• new interface methods:
  • createFutureBlock() for faster work switching, see Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants #31109
  • waitNewPowBlock() for SPV mining, see Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants #31109
  • verifyBlock(CBlock block, bool allow_rollback, bool check_pow, uint256 target)
    • for Stratum v2 pools to verify a proposed block, ignoring PoW
    • can also be used to verify weak blocks in P2pool like systems
    • can use the mempool to accelerate validation, but doesn't update it
    • (maybe) can optionally roll back, to inspect older templates

Current Template Provider users

As a stop-gap measure I plan to maintain Sjors#68 which is a continuation of #29432, since people are currently using that. Once the Mining interface makes it into a release, along with multiprocess enabled Guix binaries, I plan to drop that in favour of Sjors#48.

Additionally I plan to convert the latter from a patch set on top of Bitcoin Core into a standalone application, to make it easier for others to contribute. That should make it less dependent on my own effort. The Bitcoin Core project could decide in the future to "adopt" this project, but that is entirely uncertain and most contributors seems averse to this idea.