Bitcoin Forum

Announcing The BiRD, short for "Bitcoin Relational Database".

It is an alternative "medium-weight" Bitcoin client for Windows with the following main features:

• Talks the native bitcoin protocol: connects to the normal Bitcoin network;
  
• Maintains a pruned version of the blockchain: Mbytes instead of Gbytes of data because only "unspent" transactions are kept;
  
• Stores data into a relational database (MySQL): abstraction of the blockchain into easy SQL queries to retrieve balances and transaction details;
  
• Medium weight: storing ALL unspent transactions (in comparison to a 'light' node which would only store transactions of a specific wallet);
  
• Open-source: C++ source files can be found at github (https://github.com/thilovonbraun/bird) and can be compiled using the free MS Visual Studio C++ Express.
  
  

Goal:
To provide an alternative, medium-weight client to developers of new Bitcoin applications with a simple interface based on a MySQL database.
Nevertheless, up-to-date data including unconfirmed transactions are available (to counteract any double spend attempts).

History:
First release v0.1.0 alfa

Current weak(er) points:

• Connects to only 1 full Bitcoin client, so you have to trust that client;

More information can be found at the website UBiCard.org (http://www.ubicard.org/index.php/tech-client), including download of the compiled version and snapshots of the database at different block heights.
It will be part of a larger project including a smart card (for storing the private keys and sign transactions) and a GUI client managing the wallets, cards and payments.

Any feedback/questions is much appreciated.

Thilo von Braun

Interesting, will be watching closely the progress of this project

i like the idea of easy sql selects locally. enables many interesting applications.

so it is a rpc client? or does it use p2p commands?

if it ONLY stores the unspent ouputs, how does it react to chain reorganisations?

Can it be configured to use PostgreSQL instead of MySQL?

It uses the bitcoin p2p protocol: setting up a connection using TCP 8333, sending version/verack messages and getting data using getblocks and so on.
(just like an original Satoshi client)

The standard data flow (no chain reorganisation) is as follows:

• New blocks are downloaded first (and pre-processed = extracting info from txs) into "Chain___" tables (block and transaction data) and there is an attempt to determine their block height. This is indicated on screen by the "Count:  xxx / yyy blocks" which means: received xxx blocks from yyy in total.
• Any block more then 10 blocks deep in the chain gets pruned: tx outputs of each transaction (the new unspent outputs) are added to the "TxOutAvailable" table, tx inputs of each transaction cause their corresponding output deleted from the "TxOutAvailable". If that succeeds, the block is deleted from the chain list (the point of no return so to say)
  Status is indicated by "Pruned up to block: zzz", which will be always at least 10 less then "xxx"

If a chain reorganisation happens, the received block does not append to the end of the block chain but some blocks (mostly 1 or 2) deeper down the chain.
As BiRD maintains a chain list (and full block data) of the latest 10 blocks as explained above, it can remove the obsolete (orphaned) blocks and accept the new block instead.
Only if a chain reorganisation should occur more then 10 blocks deep, BiRD will not be able to cope that, but then there is probably something bigger going on (as in attack of the block chain).

Interesting project. I could see how this could benefit a number of services.

So is this pitched towards existing developers of bitcoin apps/sites? What's your personal goal for the service?

I started developing this client about a year ago when the official client was version 0.3.24 something.
The reason being simple: after a few tries, I couldn't get to compile it on Windows, and I need(ed) some extra features which weren't available at that time:

• easy access to any balance, not just those bitcoin addresses of the client wallet;
• "raw" transaction interface.

Why do I need those features ?
Well, I'm working on a smart card that is able to sign bitcoin transactions with a setup similar to this: smartcard <-> GUI client <-> BiRD <-> Bitcoin Network
So that's my personal goal. In fact, the project is nearly ready for its first release (but I don't like vapourware, so I did not announce anything yet).
In short, the GUI client does the following:

• talks to the smartcard to get its bitcoin addresses
• asks via BiRD the open transactions
• shows these to the user in a friendly manner
• lets the user build a new transaction
• asks the smart card to sign it
• broadcasts via BiRD the transaction into the Bitcoin network

But I think many kind of applications (websites, even smartphone apps) can benefit from BiRD (being a much easier interface to the block chain), so I decided to make it open-source and available to everyone (it's EUPL).

I think choosing MySQL for this was a bad idea. Hopefully it's not too late to switch to something else. Why not SQLite?

How does this cope with orphaned blocks?

congratulations! cool project.

it would be nice to use this as a backend for the Electrum server.  (currently, the Electrum server can use bitcoind+abe or libbitcoin)

Do you have plans to make it available for any other operating systems?

This is quite interesting. Has there been additional progress on BiRD? Has there been any thought to implementing something like MongoDB?

+1

Does this prune all spent outputs?

Have you heard the news?
About the BIRD?

https://www.youtube.com/watch?feature=player_embedded&v=2WNrx2jq184

It sounds very interesting. I will follow this