btcsuite / btcdb Goto Github PK

The database currently only saves the best chain. If a fork extends beyond the current best chain, the reorged blocks will be removed from the database. This makes the database unsafe for multiple callers who concurrently expect their given block range to be valid.

For example, when btcd must rescan some range of blocks, and the tip of the range is removed from the best chain due to a new best block, db lookups will begin failing for missing the block for some hash, or worse (if only heights are used), lookups will silently continue with no indication that previously processed blocks may not be on the same fork.

A better solution would be to use an iterator which allows walking through some range of blocks in a fork. Even if the best chain is switched, these blocks can still be iterated over. After the iteration is finished, the caller can finish (it returned results about the chain at the time the request was made) or a switch back to the main chain and/or best block can be made if more blocks were attached.

I would like to implement the btcdb.Db interface. However several of the methods don't return an error and I imagine all my methods that interact with an underlying database could potentially return an error. Am I missing something with my understanding of the btcdb.Db interface?

API needs to be changed to have it 'encapsulated'; Internally just have a byte array with bits of meaning, which is the form it is stored in the db, so faster on db load/store.

The BlockShaMissing error is not very descriptive when printed, due to the missing block sha not being included in the error string. To fix this, BlockShaMissing should be changed to a type rather than just a variable. For example:

type BlockShaMissing btcwire.ShaHash

func (e *BlockShaMissing) Error() string {
        return "block " + (*btcwire.ShaHash)(e).String() + " missing"
}

Hi,
just wondering if you had considered enabling Snappy compression for the leveldb driver?

https://github.com/conformal/btcdb/blob/master/ldb/leveldb.go#L179

given the performance statement here:

http://godoc.org/github.com/syndtr/goleveldb/leveldb/opt#Options

I'm testing btcd on a VPS with only 10GB total storage and it would be great if the blockchain could fit into that space :-)

Cheers,
Donovan.

I would like to remove Db.DropAfterBlockBySha and Db.RollbackClose as it prohibits several NoSQL datastores from using btcd due to their lax transaction/atomicity guarantees and no concept of rollback.

I just wanted to start a discussion on how feasible this would be and what the implications are before I dive in and break everything.