Bitcoin-Powered Database - Revision history

Ripper234 at 04:56, 13 July 2012

2012-07-13T04:56:29Z

← Older revision		Revision as of 04:56, 13 July 2012
Line 1:		Line 1:
			[https://booster.io/tipjar/0c9zmrc Bounty jar for this project].

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

Ripper234: /* Implementation */

2012-06-17T00:07:23Z

Implementation

← Older revision		Revision as of 00:07, 17 June 2012
Line 18:		Line 18:
	We will use a primitive PUT(message) that encodes the parameter '''message''' in the blockchain using a [[Block chain message service]].		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) ===
	CREATE(guid, version, encoding, data, owner_pub_key, hash_algorithm, signature)

	This operation creates a new record.		This operation creates a new record.
Line 37:		Line 36:
	It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation (The raw implementation of CREATE is just to PUT a message with the concatenation of its parameters).		It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation (The raw implementation of CREATE is just to PUT a message with the concatenation of its parameters).

	=== READ ===		=== READ(guid) ===

	~~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.		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.

Ripper234: /* Implementation */

2012-06-17T00:06:56Z

Implementation

← Older revision		Revision as of 00:06, 17 June 2012
Line 35:		Line 35:
	Any invalid CREATEs are ignored (e.g. CREATE with incorrect version or wrong signature).		Any invalid CREATEs are ignored (e.g. CREATE with incorrect version or wrong signature).

	It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation.		It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation (The raw implementation of CREATE is just to PUT a message with the concatenation of its parameters).

	=== READ ===		=== READ ===

Ripper234: /* Implementation */

2012-06-17T00:04:15Z

Implementation

← Older revision		Revision as of 00:04, 17 June 2012
Line 34:		Line 34:

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

			It should be mentioned that CREATE operations cost some amount of Bitcoin to be "performed" by the network - the exact amount depends on the implementation of the PUT operation.

	=== READ ===		=== READ ===

Ripper234: /* Undeletedable Asset ledger */

2012-06-16T23:59:28Z

Undeletedable Asset ledger

← Older revision		Revision as of 23:59, 16 June 2012
Line 8:		Line 8:
	== Use Cases ==		== Use Cases ==

	=== Undeletedable Asset ledger ===		=== Undeletedable, Auditable 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.		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.

Ripper234 at 23:52, 16 June 2012

2012-06-16T23:52:34Z

← Older revision		Revision as of 23:52, 16 June 2012
Line 4:		Line 4:
	* '''tamper-proof''' - If a block enters the blockchain, after 6+ confirmations this block can't be feasible faked or altered.		* '''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 [http://en.wikipedia.org/wiki/Crud 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.		A Bitcoin-powered database would be an API over the blockchain, that would expose a subset of the usual [http://en.wikipedia.org/wiki/Crud CRUD] database operations. 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 ==		== Use Cases ==

Ripper234 at 23:52, 16 June 2012

2012-06-16T23:52:03Z

← Older revision		Revision as of 23:52, 16 June 2012
Line 16:		Line 16:
	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.		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]]].		We will use a primitive PUT(message) that encodes the parameter '''message''' in the blockchain using a [[Block chain message service]].

	=== CREATE ===		=== CREATE ===
Line 40:		Line 40:

	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.		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.

			== Sample implementation of a ledger ==
			Trading websites such as Mt. Gox, GLBSE and Bitcoinica use a ledger - a system that records, for each user and asset class (BTC, USD, securities), the quantity of assets he owns at any given moment in time. Here is a simple way for such sites to implement an auditable public ledger over BPD.

			* For every user, we create both a unique encryption key and a guid. These are sent to the user immediately upon registration, and are also stored in the website's normal database.
			* For every transaction on the site, a statement comprising all of the user's assets is encoded in some format, and then written to the BPD in encrypted form, using the user's guid and encryption key.
			* At any point when the user wishes to verify his assets on the webiste, he performs a READ operation with his guid, and then decrypts his balances using his decryption key. He can then validate his current and previous account.

			Note, this system does not reduce the security of the website, because all data in the BPD is encrypted (we assume the user's computer is trojan-free - if this is an issue, the user may opt-out of receiving a copy of his encryption key ... this is still preferable to not using a BPD, because at least the site's owner would have a sure way of authenticating the ledger, that can't be deleted or tampered with ... with the assumption that the guids and encryption keys are secure and backed up).

Ripper234: Ripper234 moved page Bitcoin-powered Database to Bitcoin-Powered Database

2012-06-16T23:39:59Z

Ripper234 moved page Bitcoin-powered Database to Bitcoin-Powered Database

← Older revision	Revision as of 23:39, 16 June 2012
(No difference)

Ripper234: /* Undeletedable Asset ledger */

2012-06-16T23:39:35Z

Undeletedable Asset ledger

← Older revision		Revision as of 23:39, 16 June 2012
Line 9:		Line 9:

	=== Undeletedable Asset ledger ===		=== 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.		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.		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 ==		== Implementation ==

Ripper234 at 23:37, 16 June 2012

2012-06-16T23:37:16Z

← Older revision		Revision as of 23:37, 16 June 2012
Line 4:		Line 4:
	* '''tamper-proof''' - If a block enters the blockchain, after 6+ confirmations this block can't be feasible faked or altered.		* '''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 [http://en.wikipedia.org/wiki/Crud 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.		A Bitcoin-powered database would be an API over the blockchain, that would expose a subset of the usual [http://en.wikipedia.org/wiki/Crud 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 ==		== Use Cases ==