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)
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)
@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:

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).
pickup a blockhash automatically from stored data
How?
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.
@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.
@nikitasius Sorry, that's ridiculous. Without index, this means
getrawtransactioncould essily take minutes or hours to search through the blockchain for your transaction. If you need the data, add an index. @sipa thats why actualtxindexshould be reworked to be more flexy and more modern. Ridiculous is an actualgetrawtransactionimplementation what completely worthless on the nodes what prune the data.
Thats like:
hey folks,
getrawtransactionwas unsafe and buggy, but still worked for most of cases. Lets make it stable and ruin all what was build around.
more flexy and more modern
What you mean??
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.
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.
@nikitasius Sorry, that's ridiculous. Without index, this means
getrawtransactioncould 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
txindexshould be reworked to be more flexy and more modern. Ridiculous is an actualgetrawtransactionimplementation what completely worthless on the nodes what prune the data.Thats like:
hey folks,
getrawtransactionwas 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.
@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.
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.