* all methods: caller can supply its own consensus hash
* add RPC method to get a name's blockchain-derived history
* allow some RPC methods to proceed even while we're indexing
* add method to verify that an untrusted database file is consistent
with a (block id, consensus hash) pair.
* bugfix: track block_id --> [names] for *expiration*, not renewal
* bugfix: correctly deserialize name and namespace history
* add method to export the current database to a new file
* add method to strip name/namespace history
* add method to get the name as it was at a particular block number
* add method to get the name as it was at a particular block number
* add method to get the history of a name between two block numbers
* add method to get the set of all names and namespaces changed at a block number
* bugfix: only return a preorder hash if the object hasn't expired
* bugfix: off-by-one error when searching for consensus hash on NAME_UPDATE
* add method to get a name preorder by hash
* bugfix: use a name's namespace's 'lifetime' field to determine if it is expired.
* bugfix: on name expire, remember 'txid'
* bugfix: commit expired objects exactly once
* have each commit_() method for expired objects return the list of keys
to expired objects, so we can include them in the consensus hash.
* remember fee, op_fee, opcode, txid, and block_number for each operation.
* on NAME_UPDATE, remember the consensus hash
* bugfix: always remember the history of opcodes
* bugfix: don't store virtualchain fields
* bugfix: correct error message on namespace version mismatch
consensus hash-covered fields; generate a virtual "expire" name
operation on each block that describes the names and namespaces that
expired on that block.
consensus hash, as well as logic to use these snapshots to verify that
we can reconstruct the database at each block. These tests will be
applied systemically.
self-explanatory--for example, name_preorder_register_update_cantforce
will create a namespace, preorder a name, register it, update it, try to
update it with a different key, and verify that the different key can't
force the update.
Each test allows the programmer to define a set of wallets filled with
btc in advance, create a blockchain by describing the order of
operations on a block-by-block basis, and then query the resulting
blockstore database to verify that each operation was processed
correctly. The 'testlib.py' file serves as a common interface between
blockstore's API and the test logic--it will be stable for all tests, so
blockstore can evolve independently.
