rpc: getrawtransaction lookup by witness txid #34013

1. 
   Sjors commented at 10:31 am on December 5, 2025: member

   For Stratum v2 custom job declaration to be bandwidth efficient, the pool can request¹ only the transactions that it doesn’t know about.

   The spec doesn’t specify how this is achieved, but one method is to call getrawtransaction on each of the transaction ids listed in DeclareMiningJob (or a subset if the pool software maintains a cache).

   Unfortunately this RPC only supports txid, not wtxid.

   I think the easiest change would be:

   • have getrawtransaction accept either txid or wtxid as the first positional argument
   • add a GetTransaction that takes a Wtxid
   • try with Txid first, Wtxid if that fails
   • optionally add a “hash_type” argument: txid, txid or *

   See also:

   • https://github.com/stratum-mining/sv2-spec/issues/170

   ---

   1. there’s two reasons the pool requests these transactions: to approve the template and to broadcast the block if a solution is found (the miner will also broadcast via their template provider) ↩︎

2. fanquake added the label RPC/REST/ZMQ on Dec 5, 2025
3. 
   Fi3 commented at 11:22 am on December 5, 2025: none

   ACK for dmnd or other pools that will implement sv2 and want to do job declaration and being able to relay the blocks founded by the miners, having fast way to retrieve tx data from the node using a wtxid would be very useful.
4. 
   sedited commented at 11:26 am on December 5, 2025: contributor

   It’s not clear to me why this should happen through RPC if they are using the IPC interface already.
5. 
   Sjors commented at 11:30 am on December 5, 2025: member

   @sedited there’s different “they"s here:

   1. The miner who proposes a block, they use IPC
   2. The pool software that verifies the template and broadcasts a solution: the current SRI implementation doesn’t use IPC

   That said, I’m thinking about making an IPC method to fetch transactions more efficiently.

6. 
   Fi3 commented at 11:31 am on December 5, 2025: none

   It’s not clear to me why this should happen through RPC if they are using the IPC interface already.

   The Template Provider is using the IPC interface but the Job Declarator Server is not, and it could need to get tx data for tx in jobs declared by the miner. Having a method to do that without asking to the miner is very helpful. The Job Declarator Server could use the IPC interface, but I don’t see why this should not be possible trough the RPC interface. And as an implementor I prefer to use RPC for Job Declarator Server since IPC is very new and I don’t need it if I have this in RPC.

   https://stratumprotocol.org/specification

7. 
   plebhash commented at 11:42 am on December 5, 2025: none

   currently SRI Job Declarator Server monitors the mempool via RPC and we have considered switching to ZMQ on this issue https://github.com/stratum-mining/sv2-apps/issues/26, which is about to be tackled soon

   but I like @Sjors idea of leveraging IPC for this purpose, we can use this JDS refactoring to drive the development and stabilization of this new feature on Bitcoin Core side

   (perhaps on a separate issue on this repo?)

8. 
   Sjors commented at 11:52 am on December 5, 2025: member

   ZMQ will give you all new mempool transactions, whereas a new getRawTransactions() IPC method would only give you the ones you request. As does the RPC change suggested here.

   That’s probably enough if you keep a local cache of transactions you’ve seen before and only request unknown ones from DeclareMiningJob.

   perhaps on a separate issue on this repo

   Yes, an IPC method would need a different issue, or the pull request once I write it.

9. 
   Sjors commented at 7:15 pm on December 5, 2025: member

   See #34020 for the IPC approach.
10. 
    plebhash commented at 4:30 pm on December 6, 2025: none

    I see @Fi3 manifested interest for this, so I’d assume he still wants his JDS implementation to rely on a poll-style RPC-based design for a while

    on SRI we’re aiming for a stream-based design under the efforts for https://github.com/stratum-mining/sv2-apps/issues/26

    so IPC would be desirable, but as a potential replacement for ZMQ rawtx subscription, and not as a in-place replacement for getrawtransaction

11. 
    Sjors commented at 10:03 am on December 7, 2025: member

    for a while

    I would not expect this to land before v31 in spring 2026, so by that time @Fi3 might have finished implementing IPC support and could just use the more performant #34020.

12. 
    Fi3 commented at 7:00 am on December 10, 2025: none

    for a while

    I would not expect this to land before v31 in spring 2026, so by that time @Fi3 might have finished implementing IPC support and could just use the more performant #34020.

    yep this is likley. @plebhash about the stream style design I don’t think that is good idea, I do not want to have every tx in mempool around but just the ones that are actually added to templates.

13. 
    plebhash commented at 7:30 am on December 10, 2025: none

    @Fi3 thanks for your input!

    let’s move this discussion to #34030 and leave this issue for the RPC discussion

Contributors
Sjors Fi3 sedited plebhash

Labels
RPC/REST/ZMQ