Feature: no txid table when txindex is enabled

[antonilol]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

the txid table takes up space (is there a way to see how much?), and this data is redundant if bitcoind has txindex enabled

Describe the solution you'd like A clear and concise description of what you want to happen.

if txindex is enabled, this table is removed if it exists (to reclaim storage space when upgrading), and not indexed. getrawtransaction calls dont need a blockhash

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

none

Additional context Add any other context or screenshots about the feature request here.

useful info for implementing this:

this bitcoin-cli command shows if txindex is enabled or not and gives some info on it. the top level json object will be empty if txindex is not enabled

$ bitcoin-cli -testnet getindexinfo txindex
{
  "txindex": {
    "synced": true,
    "best_block_height": 2405719
  }
}

[Kixunil]

I'd like this too but there's a trouble when the configuration changes back. Electr will have to re-sync. This could be a significant UX hit.

[antonilol]

how many times will people enable/disable txindex? to me this is a permanent setting

the electrum queries that need the electrs txindex could return an error saying 'i am reindexing', and some messages can be logged. electrs does not have to check constantly because turning on/off txindex requires restarting bitcoind

[antonilol]

the electrum queries that need the electrs txindex

what queries need it? i believe this is only used to provide bitcoind with a blockhash for getrawtransaction, to get one specific transaction from the blockchain. when searching through blocks the entire block can be requested, no txindex needed there

[Kixunil]

Yeah, I guess people will change it at most once or twice. But still it needs to be handled making the change harder than it may seem.

when searching through blocks the entire block can be requested, no txindex needed there

Oh, yes, looking at the schema txindex should be rarely needed.

[caniko]

On that note, can somebody mention the data schema when txindex is enabled? I am assuming that we are using rocksdb for the TX index also, right?

[antonilol]

On that note, can somebody mention the data schema when txindex is enabled? I am assuming that we are using rocksdb for the TX index also, right?

txindex is maintained by bitcoind, queried indirectly using its rpc. right now the db schema does not change depending on if txindex is enabled

[caniko]

Would using rocksdb over bitcoin core for reading TX index provide any performance benefits? If so, is this the right place to add this feature?

[antonilol]

Would using rocksdb over bitcoin core for reading TX index provide any performance benefits?

no, the txid table electrs uses (about 10.5 gigabyte now) is optimized for storage usage (only 8 bytes of the 32 byte txid is stores, so collisions can occur so must be handled), whereas the txindex bitcoin core uses (about 44 gigabyte now, more than the whole electrs rocksdb) is optimized for faster lookup

relevant bitcoin source code file: src/index/txindex.cpp

[Kixunil]

@antonilol well, technically yes, but the collisions should be quite unlikely anyway, so I don't think that matters in practice. But some combinations of electrs and bitcoind versions are unfortunate because funny reasons involving txindex. That was also fixed so recent bitcoind + recent electrs is fine.