Topic: Electrum - Bitcoin client for the common users (friendly and instant) - page 31. (Read 110105 times)

I found the commit with the problem. I would like to propose the reversal of this commit unless somebody knows a way to achieve loading via the simpleconfig class but also have support for the None argument for skipping the proxy when needed.

Who did this change?

I don't think there's any problems with making the arguments optional and I certainly didn't mind that.

The problem is with the changes to how cmd line parms override the stored config and then are passed to the Interface constructor.

Currently if someone uses the master branch they can setup the proxy in the network dialog and it will work. But upon closing and reloading the program the proxy settings will not be loaded and no warning will be given. It just silently doesn't use the proxy, so if a user was intending to use Tor then without any indication it just uses the normal non-Tor connection method even though the network dialog still shows the proxy as set.

This is because the network dialog gets it's settings directly from the config file rather than active settings. The cmd line arg is parsed at start up but only if it's set is it passed to Interface. When a cmd line arg isn't given options.proxy has no value but the config is not consulted. I think the options.proxy argument to Interface needs to be replaced with

options.proxy or simple_config.config["proxy"]

to allow that if the cmd line has no setting then at least the config file setting will be used. I would note that the way I wrote it was the same way as the cmd line "gui" option was written as I tried to keep with what I saw to be precedent in the code. The reason it checked data type was because I desired that a user could temporarily disable a proxy by starting with a "-p none" option.

I also think there may be some issues with removing "none" as a valid setting and relying on None instead but I have not tested that under all conditions to see what effects that has.

looks safe to me. thanks for the patch!

This would be fantastic

There's bug in indentation on the line with "self.send_response(200)". Can you fix it, please. Otherwise this pull request is safe.

Any chance someone could take a look this pull request https://github.com/spesmilo/electrum-server/pull/5

I would like to add an electrum fallback to blockchain.info but cannot currently due to CORS.

Is genjix still involved? I haven't heard from him since the conference. I hope he's OK and will be back to lead this project soon!

+1

I just wanted to say that I love Electrum and what it does for me and I'd really love to see you guys be able to work together and set your egos aside to find a consensus and build on it rather than bicker over something that is easily solvable. 

I am very sorry if I broke things you wrote. please understand that it was not my intention.

I made several changes last week in order to fix a few scripts that were broken.
To be more precise, Tachikoma added a third parameter to the constructor of the Interface class, and you added a fourth one.
Since that class was used elsewhere, the following scripts were broken: peers, blocks, watch_address, get_history

it would have been possible to add those parameters everywhere in order to fix this.
However, I feel that we should also try to reduce the complexity of the code whenever it is possible.
I decided that the third parameter was not really needed, and that the fourth one (proxy) could be optional.

Please do not take this as an aggression. You are very welcome to work on this project.
I did not complain about my scripts being broken, because I did not want to deter your contributions.
In return, I ask you to understand that I did not break things intentionally.

I reckon I did not properly test the proxy function after my commits, mostly because there was not manual for it;
but neither did you guys check that the parameters you added were not breaking things, so let us not blame eachother, ok?

In order to avoid such misunderstanding, it often helps to have direct communication (IRC), rather than delayed forum posts.
In addition, you could have write access to the repository; this would avoid the situation where changes in the repo conflict with your version.

Lol, that 2nd paragraph is what I planned to answer when reading the first one

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.

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?

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:


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


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.

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.

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.

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.

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.

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

Do BitcoinJ nodes allow connection via Tor?

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.