rpc: add wtxid lookup support to getrawtransaction #34829

pull chriszeng1010 wants to merge 1 commits into bitcoin:master from chriszeng1010:rpc-getrawtransaction-wtxid changing 2 files +18 −3
  1. chriszeng1010 commented at 6:43 am on March 16, 2026: none

    getrawtransaction() now accepts a wtxid in addition to a txid. If the initial txid lookup fails, the hash is retried as a wtxid against the mempool. Wtxid lookup is mempool-only since the txindex indexes by txid.

    Use case

    A wallet tracking SegWit transactions receives a wtxid from a peer. To inspect the transaction, they currently have no direct way to look it up — they’d need to iterate the entire mempool to find the matching txid. With this change, they can call getrawtransaction directly with the wtxid.

    Closes #34013

  2. DrahtBot added the label RPC/REST/ZMQ on Mar 16, 2026
  3. DrahtBot commented at 6:43 am on March 16, 2026: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Reviews

    See the guideline for information on the review process. A summary of reviews will appear here.

  4. chriszeng1010 force-pushed on Mar 16, 2026
  5. DrahtBot added the label CI failed on Mar 16, 2026
  6. in src/rpc/rawtransaction.cpp:231 in c5f2fec5c3 outdated
    227@@ -228,7 +228,7 @@ static RPCHelpMan getrawtransaction()
    228                 "If verbosity is 1, returns a JSON Object with information about the transaction.\n"
    229                 "If verbosity is 2, returns a JSON Object with information about the transaction, including fee and prevout information.",
    230                 {
    231-                    {"txid", RPCArg::Type::STR_HEX, RPCArg::Optional::NO, "The transaction id"},
    232+                    {"txid|wtxid", RPCArg::Type::STR_HEX, RPCArg::Optional::NO, "The transaction id (txid or wtxid)"},
    


    stickies-v commented at 1:12 pm on March 16, 2026:

    I think stuffing two types into one field makes the RPC worse. Do we have a good rationale to do so, instead of adding wtxid as an additional parameter?

    The main benefit I see is probably that it keeps the positional cli interface simpler, but I’m not sure that tradeoff is worth it, when cli supports named args, and it doesn’t seem like this has bothered human/ad-hoc users so far?


    chriszeng1010 commented at 6:05 pm on March 16, 2026:

    I kept the signature the same to ensure minimal changes where possible for consistency.

    A single parameter is simpler for the caller — they just pass a hash and it resolves. Adding a separate parameter forces the caller to know upfront which type they have.


    chriszeng1010 commented at 4:08 am on March 17, 2026:
    I see the argument for a separate parameter — happy to refactor if you feel strongly about it.
  7. maflcko commented at 1:27 pm on March 16, 2026: member

    The lint CI fails. Also, it would be good to add a use-case to the pull description, so that it is self-contained.

    Wtxid lookup is mempool-only since the txindex indexes by txid.

    I don’t think this is true. blockhash lookup is possible too

  8. chriszeng1010 commented at 4:07 am on March 17, 2026: none

    The lint CI fails. Also, it would be good to add a use-case to the pull description, so that it is self-contained.

    Wtxid lookup is mempool-only since the txindex indexes by txid.

    I don’t think this is true. blockhash lookup is possible too

    Would you prefer I add blockhash support here or is a follow-up PR acceptable?

  9. rpc: add wtxid lookup support to getrawtransaction
    getrawtransaction now accepts a wtxid in addition to a txid. If the
    initial txid lookup fails, the hash is retried as a wtxid against the
    mempool. Wtxid lookup is mempool-only since the txindex indexes by txid.
    
    Closes #34013
    ce2ce5ab46
  10. chriszeng1010 force-pushed on Mar 17, 2026
  11. maflcko commented at 2:29 pm on March 18, 2026: member
  12. chriszeng1010 force-pushed on Mar 19, 2026
  13. luke-jr commented at 1:03 pm on March 19, 2026: member
    Why can’t the peer give you a txid?
  14. Sjors commented at 3:31 pm on March 19, 2026: member
    Maybe it’s better to add an optional (named) boolean argument that specifies whether you’re searching by witness id.
  15. chriszeng1010 commented at 5:30 pm on March 19, 2026: none

    Why can’t the peer give you a txid?

    0const auto inv = peer.m_wtxid_relay ?
    1                     CInv{MSG_WTX, wtxid.ToUint256()} :
    2                     CInv{MSG_TX, txid.ToUint256()};
    

    When a peer supports wtxid relay, it only sends MSG_WTX.

  16. maflcko commented at 7:18 pm on March 19, 2026: member

    This may be a useful feature, but it is clear that this is a low-effort LLM generated pull request, where the author obviously doesn’t understand any of it, so I think this should be closed.

    Then, an issue or pull request can be opened with a properly explained use-case and properly explained rationale.

  17. chriszeng1010 commented at 7:45 pm on March 19, 2026: none

    This may be a useful feature, but it is clear that this is a low-effort LLM generated pull request, where the author obviously doesn’t understand any of it, so I think this should be closed.

    Then, an issue or pull request can be opened with a properly explained use-case and properly explained rationale.

    I appreciate the feedback here. I’m researching the answers to the questions as they come in. This is my first contribution in this area, I’m reworking the PR with the suggested changes. If I’m not showing enough understanding, please be patient and tell me what I’m missing so I can fix it.

  18. maflcko commented at 5:49 am on March 20, 2026: member

    If I’m not showing enough understanding, please be patient and tell me what I’m missing so I can fix it.

    I am happy to answer specific questions, but the burden to understand and explain the pull request is on the author. Seeing every single review comment getting a copy-pasted and erroneous reply from an LLM shows the opposite. If you genuinely want to understand and be able to explain the changes yourself, there is an easy answer: Don’t use an LLM.

  19. Sjors commented at 12:06 pm on March 20, 2026: member

    Another approach could be to keep using this branch yourself in your local setup as you work on / with that wallet. Consider also changing the wallet code, so you can contrast both approaches.

    Then in the mean time try reviewing other RPC related pull requests here, to increase familiarity. Eventually you might find that you don’t need this change at all, or you still want it, and can try again with more confidence in the change.

  20. chriszeng1010 commented at 1:57 am on March 22, 2026: none

    If I’m not showing enough understanding, please be patient and tell me what I’m missing so I can fix it.

    I am happy to answer specific questions, but the burden to understand and explain the pull request is on the author. Seeing every single review comment getting a copy-pasted and erroneous reply from an LLM shows the opposite. If you genuinely want to understand and be able to explain the changes yourself, there is an easy answer: Don’t use an LLM.

    I’m using tools to learn and navigate the code base. But the knowledge is mine and I understood the code that I wrote. Please correct me if I’m saying anything incorrect here and I will dig deeper.

    Txid is the legacy transaction hash while wtxid hashes the transaction along with the witness data. Modern nodes uses Wtxid, while old nodes uses Txid. When a transaction is published to the P2P network, the node sends the Wtxid. This feature would be useful to anyone or any tools that wants to get the transaction data using Wtxid.

    I reproduced the issue on master branch and validated the PR-fix by running the regtest bitcoind node. I verified that every transaction contain both txid and wtxid but the current getrawtransaction only supports txid lookup, and saw error returned when I passed in a wtxid. Once the fix was applied, the same call using Wtxid returns the transaction data.

    I’m also working on addressing the design feedback from @Sjors and @stickies-v.


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-03-23 00:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me