search

CounterpartyXCP / counterparty-core

Counterparty Protocol Reference Implementation
http://counterparty.io
MIT License
283 stars 206 forks source link

Use a table other than `blocks` to store hashes ? #1393

Open ouziel-slama opened 5 months ago

ouziel-slama commented 5 months ago

This way we can avoid making updates on the blocks table.

jotapea commented 5 months ago

I can agree.

And what about storing ALL blocks pre protocol? The main benefit being a DB that can query any block out-of-the-box (great for block explorers). And is also a clear difference between this and the new "block_consensus_hashes" table.

Is a statement also, we have been tracking blocks for most of the timechain already. I would take it all the way.

And eventually, have something to start storing into the DB when the protocol can sync in parallel with Bitcoin.

It can be optional.

adamkrellenstein commented 5 months ago

I don't understand what the advantage of that would be. I don't think it'd make it easier to build a block explorer. I don't even know what data we'd store, just index and hash?

jotapea commented 5 months ago

As of now it would only be a nice-to-have, optional. Eventually who knows... And it would store the same info as all other blocks, considering hashes are moving out.