Roman Zeyde

Would it be possible to share a flamegraph please?

Sounds great :)

Maybe we can compute the "global offset" of a transaction using the following trick (IIRC, it is used by ElectrumX): - assume the transaction `txid` is confirmed at block height...

> * Make sure we're requesting non-witness blocks - no need to process witnesses. Not sure it's possible to read non-witness blocks directly from disk :( https://github.com/bitcoin/bitcoin/blob/224e90d9fdf895d3ee212edcf7dec3eb4d94ce91/src/net_processing.cpp#L1810-L1819 It would be...

The main issue is the additional storage requirements... Note that since RocksDB rows are sorted by key, prefix compression is very effective for the first bytes (which are similar between...

I thought replacing the (block_height, tx_offset) with a single global_offset :) However, I am not sure how the [design above](https://github.com/romanz/electrs/issues/547#issuecomment-949752381) will handle reorgs correctly... We can definitely start with (block_height,...

We can later find a more efficient way of encoding (block_height, tx_offset), e.g. by using 3 bytes for block_height, and 3 bytes for tx_offset - so the DB size will...

> However, I am not sure how the design above will handle reorgs correctly... For example, suppose that we store `(block_height, tx_offset)` for a given `scripthash` - and then the...

An idea - for better reorg handling, we can save for each block a list of its transactions' sizes in bytes. For example, [000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506](https://blockstream.info/block/000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506) has 4 transactions, so we'll store...

Since we save a `transaction_index` (instead of a byte offset) for each index entry, we can probably use only 2 bytes (instead of 3), so the additional storage will be...