[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[slush]

1. Concerning Qt, I do not think we need to switch to Qt, we can just provide both Qt and gtk :-)  I will not do it myself, because I am not familiar with Qt, but I will be very happy to include an alternative GUI if someone decides to write it. Note that someone already made the same proposal: https://bitcointalk.org/index.php?

Well, both toolkits can work, however I don't like splitting power in such early stage. Having two frontends needs 2x more gui development for every feature. So if you don't like Qt, then I'll try to code for that Gtk monster :-). However we should keep in mind that frontend *can* be changed in some step, so strictly isolating GUI and "backend" would be very nice. About keyboard accessibility - I'm not a fan of "rich" interfaces like skype so I don't see any problem with keeping keyboard accessibility also on Qt.

2. server polling versus push: I disagree here. I decided to use polling instead of push for a reason. Many people have difficulties configuring with firewalls and opening ports. I wanted Electrum to be as easy to use as possible, and to require

For push you don't need any open ports or some other games with firewall. Client just open persitent TCP connection to server and "subscribe" for some kind of events, like new transactions to some addresses etc. Then server route only necessary information to this socket. Keeping one open socket per one client is almost zero-cost, it brings instant updates and very low load on server (imagine that one server can serve for thousands or even tens of thousands clients; then polling and periodic database requests will be an issue).

3. the project is on gitorious. My username was already taken at github. not at gitorious :-)

lol, that's serious reason ;-). As far as I understand, almost all bitcoin developers are already on github, so hosting project here will lower barrier to get some occasional patches to electrum as well. And as far as I understand github has some very nice features for "social coding" like on-site merging of trees, patching etc. But well, it's absolutely your choice.

[1714045873]

1714045873

[1714045873]

1714045873

[1714045873]

1714045873

[1714045873]

1714045873

[1714045873]

1714045873

[1714045873]

1714045873

[btc_artist]

watching

[slush]

Indeed. well, the fee calculation in the official bitcoin client is quite complicated, and I did not take the time to reproduce it. However, when I first used the official client, it took me some time to realize that the fee was "per kB". In any case, I think that the fee should be visible from the user before they press the "send" button. Maybe we should display the suggested fee, and give the user the option to increase or decrease it.

I'm actually thinking about "coin selection" patch, so I may also redesign fee calculation. I wanted to know that you're aware of that and you also see it as "problem to be fixed". Calculating appropriate fees can be pretty tricky, because rising fee can rise size of transaction, which can rise fee again :-). Btw coin selection is yet another feature which I'm missing in official client.

[slush]

nice, thanks. I just added it to Electrum, and released version 0.27
note that I reimplemented the rendering with pygtk, because I did not want to create another dependency with IM

Great. It's sad that your code for using qrcode in pygtk is actually longer than whole QR support patch :-). I didn't know that I can directly with Gtk so sorry to give you extra work on my patch. I need to learn Gtk a bit more.

[btc_artist]

Indeed. well, the fee calculation in the official bitcoin client is quite complicated, and I did not take the time to reproduce it. However, when I first used the official client, it took me some time to realize that the fee was "per kB". In any case, I think that the fee should be visible from the user before they press the "send" button. Maybe we should display the suggested fee, and give the user the option to increase or decrease it.

I'm actually thinking about "coin selection" patch, so I may also redesign fee calculation. I wanted to know that you're aware of that and you also see it as "problem to be fixed". Calculating appropriate fees can be pretty tricky, because rising fee can rise size of transaction, which can rise fee again :-). Btw coin selection is yet another feature which I'm missing in official client.

Coin selection would be a great feature, both for avoiding fees and added privacy.

[ThomasV]

Well, both toolkits can work, however I don't like splitting power in such early stage. Having two frontends needs 2x more gui development for every feature. So if you don't like Qt, then I'll try to code for that Gtk monster :-). However we should keep in mind that frontend *can* be changed in some step, so strictly isolating GUI and "backend" would be very nice. About keyboard accessibility - I'm not a fan of "rich" interfaces like skype so I don't see any problem with keeping keyboard accessibility also on Qt.

We will definitely see more clients and implementations.
1. An android client is needed. I tried to do it in python, I compiled python for Android, but it is difficult to use. It might be easier to rewrite Electrum in java.
2. I would also like to have Electrum as a Firefox extension. This would mean a one-click install. For that, a javascript implementation is needed (I made some tests, I was able to use an electrum wallet inside the pyxpcom extension, but pyxpcom is poorly supported; better use pure javascript).

For push you don't need any open ports or some other games with firewall. Client just open persitent TCP connection to server and "subscribe" for some kind of events, like new transactions to some addresses etc. Then server route only necessary information to this socket. Keeping one open socket per one client is almost zero-cost, it brings instant updates and very low load on server (imagine that one server can serve for thousands or even tens of thousands clients; then polling and periodic database requests will be an issue).

Not sure if this works everywhere, but we'll see. For the moment my server never had more than 3 clients connected simultaneously, including mine :-)

As far as I understand, almost all bitcoin developers are already on github

No, genjix (libbitcoin) is on gitorious.

[jim618]

If you wanted to have a Java Electrum implementation you could probably reuse all the network layer in bitcoinj as that can parse the messages for blocks, transactions etc.

If I understand Electrum correctly you have your own socket transport from your client to something on your server side accepting incoming socket connections.   I do not think anyone has done that yet in Java for bitcoin - don't recall anyone mentioning it on the bitcoinj mailing list.   Mike Hearn is definitely worth talking to though before you do any serious work on a Java implementation as I bet he could save you tons of time with his suggestions.

Andreas Schildbach's implementation of Android Bitcoin Wallet is open source too so that might be a useful resource for you.   I have asked Andreas for help on various things and he is always helpful.

[ovidiusoft]

Anyone else considers useful to have the server's config file structured like a INI file, using ConfigParser http://docs.python.org/library/configparser.html ? I am also thinking of moving a little more settings into it, for example:

Code:

[server]
host = 127.0.0.1
port = 50000
password = secret
banner = "Welcome to Electrum!"

[database]
dbtype = sqlite3
dbname = /path/to/electrum.sqlite

I can probably hack something tomorrow. Also, I never used gitorious, if I create an account I can push directly to your repository?

[ovidiusoft]

Implemented here, please review (merge request pending): https://gitorious.org/~ovidiusoft/electrum/ovidiusofts-electrum

[ThomasV]

Implemented here, please review (merge request pending): https://gitorious.org/~ovidiusoft/electrum/ovidiusofts-electrum

that's great! will try to merge it soon :-)

[slush]

wohoo, just learned with git enough to work on electrum too :-)

[slush]

Ok, I'm playing with firstbits now. Unfortunately it's not so easy as I expected, it needs patch to Abe to make implementation sane and fast enough. I just asked Abe developers if they'll accept my patch as I don't like maintaining code outside of upstream.

In the meantime I'm also learning Qt and I'll try to make alternative GUI for electrum. I simply rejected the idea of learning gtk which I'm considering as prehistoric monster. Qt is opensource and free for OSS projects, I don't see the reason to not use it. However (as a real server-side guy) I hate GUI development at all, so I cannot promise that I'll finish it into usable state :-). I'd like to use slightly different approach than electrum gtk, aiming more to newbies and normal users. I pretty like dashboard idea of https://bitcointalk.org/index.php?topic=50162.0, so I'll reuse idea basics, still with many changes.

Today I thought about features I'd like to see in best-bitcoin-client-ever, there is my brain dump. Maybe if others have some nice ideas it will be good to make a pool of them to let programmers pick what they want to implement.

* Qt GUI (in early steps, not sure with results. I have many possible improvements of GUI in my head, however they're related to basic gui design, so nothing to reveal yet)
* Firstbits support (in progress)
* Erasure coding for seed backups
* Coin selection
* Direct support for printing seed
* QR decomposition & camera support
* Offline transactions
* Notification for new client version (as protocol is in early stage it's important to tell users they have to upgrade)
* Send bitcoins to email (using server-side escrow, sending back not withdrawed coins)
* Wallet in the cloud (sync wallets across multiple computers)
* Server failover (server peer switching)
* Make network layer more robust (permanent connection, interface for browser clients, but fallback to poling for restrictive networks)
* Make wallet format more robust

[BTCurious]

This may be a bit controversial because the community can't seem to decide on what they want exactly, but I still think it's important to add URI support to that list.

[ovidiusoft]

For people playing with multiple wallets/clients:

* open/close wallet(s), switch between wallets, merge/split wallets, transfer keys/coins between wallets.
* import different wallets from other clients.
* import/export keys, purge keys (for example, after an export).

Of these, using multiple wallets and importing from other clients should be a priority. I'm just sorry my GUI development skill are non-existing .

[btc_artist]

For people playing with multiple wallets/clients:

* open/close wallet(s), switch between wallets, merge/split wallets, transfer keys/coins between wallets.
* import different wallets from other clients.
* import/export keys, purge keys (for example, after an export).

Of these, using multiple wallets and importing from other clients should be a priority. I'm just sorry my GUI development skill are non-existing .

Yes!!!

[simonk83]

So I have to say, this all sounds great    I have to ask though, is it ready to go?  Safe to use?  Had plenty of testing? 

Very keen to give it a crack, but obviously there's money involved so it's always going to be a bit of a risk    I'll go read through the rest of the thread now

[ovidiusoft]

So I have to say, this all sounds great    I have to ask though, is it ready to go?  Safe to use?  Had plenty of testing? 

No, no and no . Running the client is easy enough. Running your own server is so-so (I'll write a post about it, if there's interest). You can play, I think you'll like it, but for the moment I wouldn't advise you to transfer large amounts, as there can be bugs that could eat your coins.

[simonk83]

So I have to say, this all sounds great    I have to ask though, is it ready to go?  Safe to use?  Had plenty of testing? 

No, no and no . Running the client is easy enough. Running your own server is so-so (I'll write a post about it, if there's interest). You can play, I think you'll like it, but for the moment I wouldn't advise you to transfer large amounts, as there can be bugs that could eat your coins.

Yep, I just read through the rest of the thread, so fair enough.

Exciting stuff though

[finway]

I'm learning python, hope i can contribute someday. 

[ThomasV]

I just released a new version, version 0.28

changelog:
* the wallet_dir option was replaced by a wallet filename option
* pycrypto is no longer used, it was replaced with slowaes (native python)

both slowaes and python-ecdsa are native python, and are included in the package, so the installation should be highly facilitated.

Note that the wallet format has changed. if you have encrypted your wallet, you will need to upgrade it with a script.
you can either uncrypt your wallet before the upgrade (the easiest option), or run the upgrade.py script that will upgrade your wallet to the new format.