wallet: decode raw transaction in gettransaction #16181

issue MarcoFalke opened this issue on June 10, 2019
  1. MarcoFalke commented at 7:13 AM on June 10, 2019: member

    Does it make sense to decode the raw transaction in the wallet-rpc gettransaction call (or add an optional parameter to do so)?

    See discussion in #15159 (comment)

  2. MarcoFalke added the label Brainstorming on Jun 10, 2019
  3. MarcoFalke added the label Wallet on Jun 10, 2019
  4. MarcoFalke added the label RPC/REST/ZMQ on Jun 10, 2019
  5. MarcoFalke added the label good first issue on Jun 10, 2019
  6. nikitasius commented at 9:31 AM on June 10, 2019: none

    @MarcoFalke why do you want to improve a pretty limited api call (=only for wallet tx) instead of improving a call what exists and does much more? (getrawtransaction).

    gettransaction "txid" ( include_watchonly )
    Get detailed information about in-wallet transaction <txid>
    

    With getrawtransaction i can look for ANY transaction i want:

    image

    Guess best improvements is to allow getrawtransaction to pickup a blockhash automatically from stored data (when users do not use txindex and use prune option).

  7. promag commented at 9:44 AM on June 10, 2019: member

    pickup a blockhash automatically from stored data

    How?

  8. nikitasius commented at 9:49 AM on June 10, 2019: none

    pickup a blockhash automatically from stored data

    How?

    If i store last 8Gb from blockchain on my node, client should be able to work with this 8Gb, otherwise i just waste my space for nothing.

    Thats question to bitcoin devs, HOW they can manage/operate saved data.

  9. sipa commented at 10:49 AM on June 10, 2019: member

    @nikitasius Sorry, that's ridiculous. Without index, this means getrawtransaction could essily take minutes or hours to search through the blockchain for your transaction. If you need the data, add an index.

  10. nikitasius commented at 11:22 AM on June 10, 2019: none

    @nikitasius Sorry, that's ridiculous. Without index, this means getrawtransaction could essily take minutes or hours to search through the blockchain for your transaction. If you need the data, add an index. @sipa thats why actual txindex should be reworked to be more flexy and more modern. Ridiculous is an actual getrawtransaction implementation what completely worthless on the nodes what prune the data.

    Thats like:

    hey folks, getrawtransaction was unsafe and buggy, but still worked for most of cases. Lets make it stable and ruin all what was build around.

  11. promag commented at 11:52 AM on June 10, 2019: member

    more flexy and more modern

    What you mean??

  12. nikitasius commented at 12:33 PM on June 10, 2019: none

    more flexy and more modern

    What you mean??

    it mean, what when someone run new bitcoin client with txindex and prune options, client build index using pruned data. and each time when data is prunes, bitcoin client wipe from index pruned records.

  13. promag commented at 12:38 PM on June 10, 2019: member

    What's the use case for a incomplete tx index? Anyway it's off topic here.

    Concept ACK on decoded data for wallet transactions with a corresponding option.

  14. sidhujag commented at 4:46 PM on June 10, 2019: none

    @nikitasius Sorry, that's ridiculous. Without index, this means getrawtransaction could essily take minutes or hours to search through the blockchain for your transaction. If you need the data, add an index.

    @sipa thats why actual txindex should be reworked to be more flexy and more modern. Ridiculous is an actual getrawtransaction implementation what completely worthless on the nodes what prune the data.

    Thats like:

    hey folks, getrawtransaction was unsafe and buggy, but still worked for most of cases. Lets make it stable and ruin all what was build around.

    All is needed is a new re-org aware index (blockindex) that stores a mapping between the blockhash and txid (a simpler version of txindex) so things like getrawtransaction and gettransaction can do a simple lookup of a tx without storing all the transactions in the index like txindex does. With the rework of gettransaction (ability to pass in the hashBlock) the lookup becomes performant enough imo since its a disk read, most are on SSD's now aswell.

  15. nikitasius commented at 5:05 PM on June 10, 2019: none

    @sidhujag exact.

    Even HDD not an issue, due new code can add index on fly (during loading new tx from blockchan), or run a heavily scan once if there are no index found for pruned data.

    Much more useful to focus resources on this task instead of decoding raw tx in gettransaction call, due getrawtransaction have huge potencial and very universal and useful call.

  16. sipa commented at 5:20 PM on June 10, 2019: member

    The reason txindex isn't supported together with pruning is because we haven't heard of any use cases for (another) unreliable index. In my expectation, if you have a need to look up arbitrary transactions, you probably need them for the entire chain. Having it work for an ever-changing set of last few blocks is likely more confusing than helpful.

    If you have a good use case for this, I'm all ears.

  17. jnewbery commented at 6:07 PM on June 10, 2019: member

    No objection to adding additional raw tx data to the wallet's gettransaction RPC method if users think that's useful. Discussion of changes to getrawtransaction should be discussed in #16182.

  18. meshcollider closed this on Sep 2, 2019

  19. sidhujag referenced this in commit 7fb1dcfa08 on Sep 3, 2019
  20. MarcoFalke locked this on Dec 16, 2021
  21. knst referenced this in commit 03dccfcfa4 on Mar 1, 2023
  22. knst referenced this in commit 7d431ecc40 on Mar 2, 2023
  23. knst referenced this in commit b25fdfac72 on Mar 15, 2023
  24. knst referenced this in commit 99c72df57d on Mar 15, 2023
  25. knst referenced this in commit bb9cc91592 on Mar 19, 2023
  26. knst referenced this in commit 9b8ab762ca on Mar 28, 2023
  27. knst referenced this in commit af66abd429 on Mar 28, 2023
  28. knst referenced this in commit c01cde6c82 on Apr 6, 2023
  29. UdjinM6 referenced this in commit 4c72e6966d on Apr 6, 2023

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-04-13 15:14 UTC

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