Electrum - Bitcoin client for the common users (friendly and instant)

[flatfly]

Actually the command line already supports this (try "electrum -o history" or "electrum -o balance")  since, as bkkcoins said, the wallet file already contains all the required info. So I imagine it shouldn't be too hard to adapt the gui_qt code accordingly.

[rexcoin]

Based on my experience, the client uses about 28-30MB RAM.

SO sorry went to sleep,
Ah 30 mb ram? thats great! thanks so much flatfly!

[BkkCoins]

I was thinking of adding an option to force currency exchange price requests thru the proxy if one is set. This is so that you don't get local data leakage when using Electrum thru a proxy / Tor.

I'm wondering if it needs to be an option or if it should just always use the proxy if one chosen?

Any input on this?

[slush]

Hehe that's exactly the reason why only Stratum connection should be used for communication with the rest of the world. Electrum server should expose RPC call providing current exchange rate and client should just call it instead of using separate http connection.

Any chance to do this instead of hacking httplib to go thru proxy?

I was thinking of adding an option to force currency exchange price requests thru the proxy if one is set. This is so that you don't get local data leakage when using Electrum thru a proxy / Tor.

I'm wondering if it needs to be an option or if it should just always use the proxy if one chosen?

Any input on this?

[hazek]

Definitely the second, it should go through proxy by default if one is set.

[BkkCoins]

Hehe that's exactly the reason why only Stratum connection should be used for communication with the rest of the world. Electrum server should expose RPC call providing current exchange rate and client should just call it instead of using separate http connection.

Any chance to do this instead of hacking httplib to go thru proxy?

I tend to agree that security wise the best option is a single connection to the server. But it also lacks flexibility. I already did a re-org of the exchange code in my fork, creating "lib/exchanges" subdir, that allowed a choice of exchange using a module for each exchange site. I created a MtGox exchange  module in addition to the Intersango one already there by default. The nice thing is foreign users who want some particular exchange rate (eg. Yen, Ruble etc) could select the exchanger in the Settings dialog.

Having only support thru the Electrum server would limit what was available for users to whatever the server decided to offer for quotes. But I could easily create a module that directed quote requests to thru current Electrum server so that users have the option of using Electrum quotes or any other exchanger module available. Right now the server doesn't have an exchange quote api but that could be created.

So at this time it seems the best option is to wrap exchanger modules for proxy use, if one is selected, so that at least leakage won't occur. Then later we could add an exchange api to the server and a Electrum exchanger module for clients. At that point users would have ultimate flexibility in this area. They could choose native Electrum quotes or optional external quotes.

Feedback?

[marcus_of_augustus]

So at this time it seems the best option is to wrap exchanger modules for proxy use, if one is selected, so that at least leakage won't occur. Then later we could add an exchange api to the server and a Electrum exchanger module for clients. At that point users would have ultimate flexibility in this area. They could choose native Electrum quotes or optional external quotes.

Feedback?

Sounds sensible.

[slush]

I agree that fixing just a proxy sounds easier for now. Although using stratum servers for price quotes makes more sense, currently it has quite low priority.

I know that intersango quote was quick hack done by genjix, but I'd appreciate if future features will be implemented correctly (over the Stratum servers) than adding more and more separate channels into the client.

[BkkCoins]

I've now got a fix for exchanges using proxy when selected. The new code is in my fork bkkcoins/electrum branch exchanges-proxy but it also depends on branch multi-exchange so that would need to be pulled in first.

[Tachikoma]

Bkk, would it be possible for you to create pull requests for specific functionality. So we can asses on a per feature basis if and how to merge it back into master?

At the moment it's quite hard to assess this because you have been so active ^^

[ThomasV]

Bkk, would it be possible for you to create pull requests for specific functionality. So we can asses on a per feature basis if and how to merge it back into master?

At the moment it's quite hard to assess this because you have been so active ^^

@bkk: also, you're welcome to come and discuss on IRC. it is much more efficient

[BkkCoins]

Bkk, would it be possible for you to create pull requests for specific functionality. So we can asses on a per feature basis if and how to merge it back into master?

At the moment it's quite hard to assess this because you have been so active ^^

My plan was to test multi-select spends more. Then try to merge the current master to my fork so I'm current. I could then merge each of my feature branches in and resolve any conflicts due to other changes. Then for each feature send a pull request that should be right up to date. I treat my merged-2 branch as a local work copy for me as I use it to create a python build and install for real into my system.

@bkk: also, you're welcome to come and discuss on IRC. it is much more efficient

I'm not much of an IRC user. Every time I go on there I stumble around trying to figure out what to type and whether I'm treading on people's toes. I'm tied up for the next couple hours but I'll try it out after and see if I can get some better communication going.

I also think I need a better IRC client as I'm using Empathy and it doesn't seem very good overall. If I had something with IRC and OTR messaging that I could use I might actually be tempted to leave it running as I no longer trust Skype.

[flatfly]

Actually Matt has implemented bloom filters in bitcoinj already. It's just pending merge. So you don't need to do any work Jim, just keep up with bitcoinj and at some point you will get this feature "for free".

Once bloom filters are implemented and rolled out across the network, I don't see any reason for Stratum/Electrum-style servers any more. With some more optimization you can theoretically match their efficiency but without any need for a semi-trusted server.

Interesting development on the bitcoinJ front... I'm not qualified to comment on it from a technical point
of view, so I would really like to hear any comments from the experts

Not sure how technically feasible it is (it would perhaps require some protocol changes and cooperation with bitcoinJ devs), but perhaps it would be nice if Electrum (the client) could eventually get the ability to directly connect to BitcoinJ nodes (in addition to Electrum servers)?

If this is possible, I think it could actually be a good thing for Electrum in the long run, as it would bring a nice solution to the issue of having potentially malicious servers.

[marcus_of_augustus]

Actually Matt has implemented bloom filters in bitcoinj already. It's just pending merge. So you don't need to do any work Jim, just keep up with bitcoinj and at some point you will get this feature "for free".

Once bloom filters are implemented and rolled out across the network, I don't see any reason for Stratum/Electrum-style servers any more. With some more optimization you can theoretically match their efficiency but without any need for a semi-trusted server.

Interesting development on the bitcoinJ front... I'm not qualified to comment on it from a technical point
of view, so I would really like to hear any comments from the experts

Not sure how technically feasible it is (it would perhaps require some protocol changes and cooperation with bitcoinJ devs), but perhaps it would be nice if Electrum (the client) could eventually get the ability to directly connect to BitcoinJ nodes (in addition to Electrum servers)?

If this is possible, I think it could actually be a good thing for Electrum in the long run, as it would bring a nice solution to the issue of having potentially malicious servers.

Interesting development, wonder if this has anything to do with Electrum's recent Torify capability implementation?

Do BitcoinJ nodes allow connection via Tor?

[BkkCoins]

If this is possible, I think it could actually be a good thing for Electrum in the long run, as it would bring a nice solution to the issue of having potentially malicious servers.

If Electrum could connect to BitcoinJ nodes then I think there'd be little use for Electrum servers.

I'm not up on "bloom filters" but if it means that it can run without a full blockchain then the best path forward would not be connecting to BitcoinJ nodes but rather porting the BitcoinJ bloom filter code into Electrum client so that servers aren't needed, and Electrum can connect to any other node. At this point I have no idea what's involved.

[slush]

I don't think that even super-lightweight bitcoin protocol fully replaces the concept of Electrum server/client for one reason - simplicity. Client requesting high-level commands to (Electrum) servers will be still much easier to implement than anything directly communicating over bitcoin network. For example I don't think it will be ever possible to ask for address balance/history by a single HTTP request to bitcoin node, like it is Electrum android client doing these days, traversing all stupid firewalls and proxies on the way.

However the idea of bloom filtering and lightweight bitcoin nodes is very interesting for Electrum server implementation.

[BkkCoins]

I don't think it will be ever possible to ask for address balance/history by a single HTTP request to bitcoin node, like it is Electrum android client doing these days, traversing all stupid firewalls and proxies on the way.

I would expect any implementation to be provided as a library/module such that the client would be able to use it with similar simplicity to how it uses http now.

However the idea of bloom filtering and lightweight bitcoin nodes is very interesting for Electrum server implementation.

This would be very interesting as right now the overhead to setup an Electrum server is substantial. An Electrum server that could pull in a library and be self-contained and as easy as setting up as, say, Apache by way of a package with one command, would be worth pursuing.

[jim618]

Hello the Electrum thread!

Matt Corallo and Mike Hearn's work on Bloom filters is really interesting so I thought I would cross post some of Mike's URLs:

<Mike on>
Bloom filter on the Satoshi side is here:

https://github.com/bitcoin/bitcoin/pull/1795

on the bitcoinj side is here:

http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter
</Mike off>

There is a little graphic from London 2012 that shows that there are changes to both the bitcoinj clients and bitcoind:
http://multibit.org/postImages/bloom.png

I think it is the changes to the bitcoind that would be of most interest to you as you can use them to cut down the amount of data you have to process. Slush is right though : you do lose the ability to get the transaction outputs of a random key (as the bloom filter is created from a set of addresses/ public keys and then 'set' onto the bitcoind end of the connection to filter the data).

Worth keeping an eye on this area definitely.

[BkkCoins]

I must say that I'm more than a bit peeved that my proxy code was rewritten and broken. The changes in current master break the ability to load a proxy config. I looked at the changes and thought it was broken but had to pull the current master branch to be sure. I also don't much like the numerous minor syntax changes. What I wrote was tested and worked and now it's a broken mess.

Currently if you set a proxy mode and save it will not get picked up when you start again. It also breaks the ability to disable a proxy to None with a cmd line option since None is no longer supported. These are things I tested fairly extensively before submitting my code. The changes also break fine tuning I made later and probably will result in conflicts when bringing in further improvements I've since made.

I've got whole slew of small and useful changes in my fork and I don't plan to do pull requests on any of them. All of the below are tested as working on my system. No one seems to have bothered testing them elsewhere. Socks support worked too before it was mangled up.

  confirmation-tooltips - use tooltip for confirm count instead of passing tx data
  exchanges-proxy-mode - proxy support for exchanges
  filter-history - show only selected address transactions
  import-addr-or-key-only - add watch only address support
  multi-exchange - allow selecting which exchange to use for quotes
  multi-select-send - easy coin control
  pro-show-currency - add currency quote next to balance in pro mode
  qr-scalable-centered - make qr code scale with window and centered
  red-debits - show withdraw/payments in red text as std for accounting
  remember-column-widths - stop having to re-set column widths
  sahara - new sandy brown theme
  shrink-gui-lite-settings - allow changing back to Lite mode from Pro

Right now, I'm a quite disgruntled with how this project is run. I'm not going to write code to just have it f'd with and overridden with breaking changes. I'd love to see Electrum improve but if the current devs prefer it stagnate then no problem, I can go put my efforts elsewhere.

I don't see that point of me testing my code extensively just to have it merged into master and then edited without my knowledge and broken. Shouldn't breaking changes be tested before merging in master? Doesn't that make bloody sense? Is there any rules about flow here or do people just edit willy nilly in master branch as they please?

[Tachikoma]

I must say that I'm more than a bit peeved that my proxy code was rewritten and broken. The changes in current master break the ability to load a proxy config. I looked at the changes and thought it was broken but had to pull the current master branch to be sure. I also don't much like the numerous minor syntax changes. What I wrote was tested and worked and now it's a broken mess.

Currently if you set a proxy mode and save it will not get picked up when you start again. It also breaks the ability to disable a proxy to None with a cmd line option since None is no longer supported. These are things I tested fairly extensively before submitting my code. The changes also break fine tuning I made later and probably will result in conflicts when bringing in further improvements I've since made.

I've got whole slew of small and useful changes in my fork and I don't plan to do pull requests on any of them. All of the below are tested as working on my system. No one seems to have bothered testing them elsewhere. Socks support worked too before it was mangled up.

  confirmation-tooltips - use tooltip for confirm count instead of passing tx data
  exchanges-proxy-mode - proxy support for exchanges
  filter-history - show only selected address transactions
  import-addr-or-key-only - add watch only address support
  multi-exchange - allow selecting which exchange to use for quotes
  multi-select-send - easy coin control
  pro-show-currency - add currency quote next to balance in pro mode
  qr-scalable-centered - make qr code scale with window and centered
  red-debits - show withdraw/payments in red text as std for accounting
  remember-column-widths - stop having to re-set column widths
  sahara - new sandy brown theme
  shrink-gui-lite-settings - allow changing back to Lite mode from Pro

Right now, I'm a quite disgruntled with how this project is run. I'm not going to write code to just have it f'd with and overridden with breaking changes. I'd love to see Electrum improve but if the current devs prefer it stagnate then no problem, I can go put my efforts elsewhere.

I don't see that point of me testing my code extensively just to have it merged into master and then edited without my knowledge and broken. Shouldn't breaking changes be tested before merging in master? Doesn't that make bloody sense? Is there any rules about flow here or do people just edit willy nilly in master branch as they please?

Hey Bkk,

I haven't been able to code or do much Electrum related work these last two weeks. The last thing I did was merge your merged branch into master. I did talk with ThomasV who said that you broke a few key parts and he needed to fix them. I will ask him to take a look at your comments here.

I do appreciate all the work you have done, and I understand that it must be really frustrating to see that it is now broken.

The main problem is that at this moment there is no real "leading figure" for Electrum, what happened to you is probably a result thereof.

I want to get this off my chest because hopefully it will spark a change that will get Electrum back on the right track again. A couple of months back, when I first stumbled on Electrum I was in love with the concept. I've made a few commits to the Gui, mainly because I loved the Satoshi style confirmation icons and I thought it might be a need little addition. My pull request wasn't commented on for a couple of days so I decided to jump on IRC to see if I could get in contact with ThomasV and discuss it. That's where I was greeted by Genjix who explained that he was working on a new Gui, which is now the 'Lite GUI'. I did not like the default style so I decided to work it over to what it is now. Genjix was very willing to work with me and build in new features where ThomasV was taking a more conservative approach. Since the changes I was working on were on the Lite GUI and not the original one by ThomasV it did not matter at that point.

Now this is were I'm a bit fuzzy and either Genjix or ThomasV should comment. But at one point I think Genjix and Thomas met to discuss Genjix taking over Electrum. A few weeks after this meeting the Lite gui got released and pushed as default gui. The 1.0 release went out with the new website and the move to github. Looking back at things I think there might have been a miscommunication at this point between Genjix and Thomas and I got the feeling Electrum might have been 'kidnapped' at this point. The problem was that shortly ater the 1.0 release Genjix disappeared because of the conference planning he was doing. There were loads of questions about Electrum popping up but nobody was answering them. Genjix was probably busy with the conference and I think Thomas was pissed off because of the changes Genjix pushed through, leaving Electrum empty handed.

I stepped in to answer questions in the multiple threads as much as I could and try to do my best to merge pull requests into master and to fix bugs that popped up. I, however, never asked for this job. The only reason I'm doing it is because nobody else is. I am not the right person for the job. I did not create Electrum and I only have a few months of experience with Python. This project deserves to be run by somebody who can manage it all.

I greatly respect ThomasV and Genjix for the unique qualities that they posses. Genjix is great at gathering a community and embracing the best of open source where ThomasV has the great technical skill and knowledge required to build such a sophisticated piece of software. But they are both trying to achieve different things with the same client. Genjix want's a user friendly client that everybody can use, where as I think Thomas is more interested in building a very powerful tool for more experienced users.

I love Electrum, it's the best client out there and I would hate to see passionated contributers like Bkk turned away because of internal miscommunication.

Electrum needs vision and leadership again and I think it's up to Thomas and Genjix to decide how they want to advance.