Bitcoin Box

Ads

Interview with MagicalTux On QBitcoin

author: Kiba
published: 2011-03-22 03:55:50 UTC

QBitcoin is an upcoming bitcoin client written by Mark Karpeles aka MagicalTux. I was a curious about this upcoming client, so I decided to interview the author behind the software.

Kiba: So, before we get to the topic of QBitcoin, would you introduce yourself?

MagicalTux: Ok, I'm Mark Karpeles, a 25 years old french developer who moved to Japan (mainly because I was tired of life in France) one year and half ago to build a new company here. I do many things, this includes development, business management, and other random things. I contributed to various open source projects (usually by submitting patches or becoming maintainer) and wrote my share of software people do not want to see, which gets a large share of trolls (a mail server in PHP, a FTP server in PHP, a DNS server in PHP, etc)

With my company I opened services such as KalyHost.com and integrated bitcoin support in it. I also made a bitcoin-only service called smsZ.net and planning on various new bitcoin-based services.

Kiba: So, QBitcoin is a bitcoin client, like the official Bitcoin client. In what major ways does it differs from the official bitcoin client?

MagicalTux: There are many differences. The most obvious one is the choice of Qt over wxWidgets+boost.

There are several advantages of using Qt over wxWidgets+boost. The main one is the ability to use the same native types between GUI and other parts (networking, etc). This makes the whole code easier to read and understand. Qt also provides tools for almost all the features needed, including networking, JSON RPC, etc...

The other difference comes from the fact the wallet is separated from the main executable. This feature has been requested a few times (avoid a process which accesses network to know the private keys) and has been implemented here. I have decided to also include support for encrypted wallet, using a RSA 4096 bits key encrypted via AES256. The complex part in the encryption process was to allow creation of new bitcoin addresses at any time without password, while requiring a password to use them.

In theory it should also be possible to use any external encryption device, this would just require some specifications/drivers (not planned yet).

This client will also be able to connect to many bitcoin networks at the same time, and handle more than one blockchain at the same time. This is the first step required to start including other "things" (bitDNS?) into bitcoin (in the meantime it'll allow to be on both testnet and main at the same time)

Finally I decided to take feature requests, which will lead to many less-critical features:

• Configurable transaction view (choose columns, order, etc) Skinnable GUI (using Qt's CSS skins) uPnP support
• Port randomization
• Fee configuration interface (either when sending transactions or generating blocks)
• Automatic updates when using the official builds

The full updated list is on the wiki

Kiba: The feature request list sound like a lot like feature creep. How do you manage that and still hopefully crank out a nice version of QBitcoin that people like to use?

MagicalTux: The keywords are modularity and options.

While all those features will eventually be integrated into QBitcoin (at least all those I accepted) they will be enabled only if they do not cause extra hassle for the user.

For example wallet encryption will not be enabled by default, since it is the current behavior, however the user will be able to get into the settings, click "Security" and input a password. Starting this point sending bitcoins will require the password. If the user do not like that he can still get back to the options screen and disable encryption.

Hopefully people will be able to find how to enable option they want, and use them (a lot of documentation and some nice screenshots should help)

Kiba: That sound like an awful lot of complexity since you have so many optional combination that you must test for. You aren't worried about the possible bugs that might crop up in adding such configuration complexity?

MagicalTux: The system is mostly modular, so a feature should have no impact on other features (and most of the requested features are only GUI/cosmetic, which makes them have a really low impact on anything).

For big features such as wallet encryption, however, I took a different way of doing things. Wallet encryption will be "enabled" all the time, except the key used for RSA encryption will be stored as is. This way, if anything goes wrong with the ECC private key encryption, I'll know it immediatly (since I'm unlikely to use any password for my test builds, having to type in a password each time would be a pain).

Finally, I'll be running unit tests on /most/ of the code, using valgrind to test for memory leaks and callgrind to analyze code coverage. While I will probably not be adding testcases for every single possibility, I'll try to at least have test cases for bugs/problems reported during beta.

Kiba: The wallet encryption feature sound nice. However, others have pointed out on the forum lately that such protection are still vulnerable to Trojan horses spying on user typing in passwords. It also give the users a false sense of security. How will you be addressing this problem if in any way at all?

MagicalTux: We all know there is no protection that works against everything. I mean, on your computer you also type your bank account details and many things about yourself (emails to close relatives, to banker, etc).

Whatever security you provide, there will always be someone who will come up with a way to counter it.

The only thing we can do in terms of security is to make things harder and harder. If someone manages to get on someone else's computer, of course he can steal the wallet. If we add wallet encryption he'll have to wait for the user to enter his password. We could also handle encryption hardware devices (usb RSA keys for example), but what stops someone from stealing your keys ?

In the end the wallet is just what it is, a wallet. We can however add protection features. Encryption is more aimed at allowing secure backups of the wallet, but will also help if, for example, you return your computer to support and left your wallet file there, or sell your laptop with your wallet file still on there.

But the problem is still the same: we can't save users from themselves. We try, hard, but we can't cover each and every single possible case (I've been thinking about OTP devices too, but this seems rather expensive).

Anyway we'll see how people react to this feature, and add some explanations when enabling wallet encryption (educating the user is the only way we can help him, in the end).

Kiba: When will we expect the first public release of QBitcoin?

MagicalTux: The first beta release is planned for mid-january ~ end-of-january. Starting there, the beta will probably last for a few weeks, maybe months, depending on the amount of problems found by testers, then we will will have a stable release.

Of course those times are purely informative, and I may encounter some blocking problem causing delays for the beta/final release.

Kiba: I noticed that the bitcoin wiki article on QBitcoin feature a donation address for your project. Does that mean that your project is pure donationware or are you planning a serious commercial enterprise with QBitcoin?

MagicalTux: The use of QBitcoin itself will be 100% free, with the software provided opensource under a non-restrictive license (probably some kind of BSD-based license).

I am however planning in the features to come to add the ability for users to subscribe to a wallet backup service, if their wallet is encrypted.

They will be able directly from the QBitcoin interface to subscribe (enter a few information such as login/email/password) and pay in bitcoins (probably something like 1 bitcoin per month) to have their wallet automatically backed up. No need to do anything else, the bitcoin client will send incremental data (newly generated addresses) to the server when it happens.

The backup data will be different from a normal wallet in the sense only private keys will be saved (no public key), this means the backup server will not even be able to know how much each wallet hold, or link bitcoin addresses together.

Of course anyone will be able to configure their own backup server too, and apply different pricing (or make that free), however being the "default choice" should help bring in some customers (and the backup space here will be made rock solid, with saves in different countries/etc).

From there, restoring a wallet is rather easy, just launch a newly installed QBitcoin, put your login/password, get your wallet downloaded then enter your wallet passphrase, and it'll be rebuilt in a matter of seconds. If your wallet was stolen by someone, it is highly recommanded at that point to refresh the wallet (create a new address, send coins there, delete the previous addresses... I'll try to have something to do that automatically later).

(note that login/password are not stored in the client settings, only a secure token is kept, which means authenticating a new QBitcoin installation will "disconnect" the other bitcoin client)

Kiba: What platforms will QBitcoin be available. Will it be available on mobile OS such as iphone and android?

MagicalTux: Initial release will only target desktop platforms (macos/linux/windows), however the non-GUI parts should run fine on mobile devices.

I know Qt (which was bought by Nokia) is made to run on Nokia's Symbian devices and Windows CE 5.0. I also know at some point Qt had plans to be compatibles with other unix mobile devices such as iPhone (unlikely as Apple is not a big fan of Nokia) and Android. I haven't followed the decisions taken around Qt after that, so I don't know how far those are (probably not anytime soon). However the daemon version should still run fine as all of those are still UNIX based devices.

It seems that Qt also supports Maemo and MeeGo, but I have no idea what those are. See http://qt.nokia.com/products/platform/platforms

Kiba: At the beginning of this interview, you mentioned including multiple bitcoin chain and as well other things like BitDNS. Does this mean QBitcoin's scope goes beyond just supporting the bitcoin currency?

MagicalTux: The initial goal is to implement the bitcoin currency by using a generic implementation. The long term goal being having the ability to use this generic implementation for other purposes.

Having a single client able to handle more than one chain will also allow to do things such as solving blocks on both chains at the same time.

I'm planning for a simple "BitDNS-like" implementation soon after the first releases, however this implementation may be more of an example, and will probably be different from what people expect (I do not wish to enter into details at this point about this as the original BitDNS specification has evolved, and I do not know its current status. I do however know how I'll implement this).

Kiba: This last question conclude the interview. Do you have any other Bitcoin related enterprises and projects other than what you talked about in the first question of the interview?

MagicalTux: Nothing else yet, however I believe the release of QBitcoin will open new possibilities. For now I'm trying to get QBitcoin reach a stable state, and will be looking for new ideas after that. I'd guess the next focus will be about trying to find a way to make bitcoin transactions faster (ie. a few ms). I already got a few ideas to manage this.

Sorry for taking so long during this interview, things are not always easy when doing so many things at the same time :) Hope to hear from you again soon :)

Random Articles

blog comments powered by Disqus