bitcoin: (slow) txindex in conjunction with pruning
Usecase: running a pruned peer on low resource hardware while still not want to completely loose the potential to grab any transaction by it’s txid.
Idea:
Instead of storing the CDiskBlockPos in the WriteTxIndex, it could store the blockhash (I guess its would be slightly more data and if that is a problem, maybe something with the height could work)
In case of a pruned peer, if the block on disk is not available, it could fetch the block from other peers and locate the transaction either directly with the txid of with the CDiskTxPos::nTxOffset.
If network speed is acceptable, a response within sections through getrawtransaction() may still be possible.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 7
- Comments: 15 (13 by maintainers)
@reardenlife what about
getblock $blockid 2, this give you all transactions in one request.If I understand correctly, this would be very inefficient without additional extensions to the P2P protocol, since if you wanted to actually fetch the transaction data for a tx that’s not in a locally stored block you would have to download the full block. I can see how it would be useful though if you were in a kind of semi-trusted setup (e.g. querying a full node that you can access over a local network).
Would the pruned peer immediately drop the block, or keep it around for some time - if so, how? Can we just append it to the blocks on disk and have it fall out after pruning LIFO style?