Bitcoin-Powered Database

As far I know, the Bitcoin blockchain is pretty much the only data structure that is both global and tamper-proof.

• global - There is one global instance of the blockchain (up to forks ... which are then resolved).
• tamper-proof - If a block enters the blockchain, after 6+ confirmations this block can't be feasible faked or altered.

A Bitcoin-powered database would be an API over the blockchain, that would expose a subset of the usual CRUD. operation. In fact, it would be an append-only data structure, because nothing can ever be really deleted from the blockchain - so only CREATE and READ operations will be implemented. Object Versioning will be used to emulate updates and deletions.

Use Cases

Undeletedable Asset ledger

On May 2012, Bitcoinica was hacked, and its ledger database was deleted. If its ledger were managed on a global, tamper-proof database, this would not have been possible.

Such a ledger can be constructed in a way where each balance is encrypted by a key known only to the site operator and the owner of the balance, in order to keep the account balance private. While a Bitcoin-Powered Database might not have adequet performance characteristics to perform as the backend of most websites, it can be used as a persistent data backup, that can be independently verified by a websites users.

Implementation

Regular databases are composed of a server and a client library. In this case, the "server" is all the miner nodes, so only a client library is needed. All operations are encoded as Bitcoin transactions.

We will use a primitive PUT(message) that encodes the parameter message in the blockchain using a [[[Block chain message service]]].

CREATE

CREATE(guid, version, encoding, data, owner_pub_key, hash_algorithm, signature)

This operation creates a new record.

• guid - a unique ID identifying this object, generated by the client.
• version - an object version number.
• encoding - enum identifying the encoding of the data (e.g. 0 for json, 1 for zipped json, ... other formats can be added if needed)
• data - application specific. The data should be decoded according to the ***encoding*** parameter.
• hash_algorithm - An enum specifying which cryptographic hash function is used to verify data (0 for RSA+bcrypt, ...).
• owner_pub_key - A public key identifying the owner of this object (e.g. using RSA)
• signature - hash over all the other parameters - e.g. (bcrypt(RSA_encrypt(private_key, (guid, version, encoding, data, hash_algorithm, owner_pub_key))).

The first time a CREATE operation is used with a particular guid, its version should be equal to 0, and any owner_pub_key can be provided. Any subsequent CREATE op with this guid must have the same owner_pub_key, and must have a version equal to 1+max(previous versions of objects with the same guid).

Any invalid CREATEs are ignored (e.g. CREATE with incorrect version or wrong signature).

READ

READ(guid)

This operation returns an array of all the valid version of an object with this guid (or an empty array if the object does not exist). It is naively implemented by traversing the blockchain and looking for the first message with this guid, storing the owner_pub_key, and moving forward from there, identifying the valid versions and discarding invalid ones. This naive implementation is very costly (O(blockchain size)), but can be cached.