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

[molecular]

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.

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

[ThomasV]

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.

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?

[hazek]

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. 

[World]

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. 

+1

[flatfly]

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!

[piuk]

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.

[slush]

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

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

[ErebusBat]

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.

This would be fantastic

[ThomasV]

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

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

looks safe to me. thanks for the patch!

[BkkCoins]

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

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.

[marcus_of_augustus]

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.

Who did this change?

[Tachikoma]

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.

[ThomasV]

I believe I fixed the proxy issue.
Please let me know if there are other problems.

There are still a few things that I do not like in the current way it works.
For example, if you override the proxy setting with the command line, it is not clear if the gui should save the new setting.
In addition, the network window is awkward. If proxy is disabled, the host and port entries should be disabled.

[Tachikoma]

I believe I fixed the proxy issue.
Please let me know if there are other problems.

There are still a few things that I do not like in the current way it works.
For example, if you override the proxy setting with the command line, it is not clear if the gui should save the new setting.
In addition, the network window is awkward. If proxy is disabled, the host and port entries should be disabled.

I will verify the changes tonight.

I would find it logical if the arguments you supply to the command line are for one run only. If you supply the -w argument for instance, it does not open up that wallet on each consecutive run. This matter makes the most sense to me.

I can modify suggested changes to the GUI to make it less awkward.

[ThomasV]

I will verify the changes tonight.

thanks.

I would find it logical if the arguments you supply to the command line are for one run only. If you supply the -w argument for instance, it does not open up that wallet on each consecutive run. This matter makes the most sense to me.

I don't think it's a good comparison.
The problem comes from the fact that the -p option is the only command line option that can conflict with saved preferences.

I can modify suggested changes to the GUI to make it less awkward.

that would be nice. thanks!

[Tachikoma]

I would find it logical if the arguments you supply to the command line are for one run only. If you supply the -w argument for instance, it does not open up that wallet on each consecutive run. This matter makes the most sense to me.

I don't think it's a good comparison.
The problem comes from the fact that the -p option is the only command line option that can conflict with saved preferences.

So one vote for, one against. Community help out here ^^

I will verify the changes tonight.

thanks.

I had to make one small commit to handle the fact that my config file was still using the original default parameters. Anybody who used master should now fallback gracefully to the new default. I would appreciate if you could double check it.

I can modify suggested changes to the GUI to make it less awkward.

that would be nice. thanks!

I will try to do this later tonight if I get the time

[BkkCoins]

I would find it logical if the arguments you supply to the command line are for one run only. If you supply the -w argument for instance, it does not open up that wallet on each consecutive run. This matter makes the most sense to me.

I don't think it's a good comparison.
The problem comes from the fact that the -p option is the only command line option that can conflict with saved preferences.

So one vote for, one against. Community help out here ^^

How so? If you use -g it overrides the gui just for one run. If you use -w it uses the wallet you specify but doesn't change the default. It's pretty normal for a cmd line option not to alter default configs. Until recent changes there wasn't even a saved config outside the wallet. I don't think that the cmd line options should be used to alter the saved config permanently. Unless it's explicit, like a -save option. IMO.

[ThomasV]

How so? If you use -g it overrides the gui just for one run. If you use -w it uses the wallet you specify but doesn't change the default. It's pretty normal for a cmd line option not to alter default configs. Until recent changes there wasn't even a saved config outside the wallet. I don't think that the cmd line options should be used to alter the saved config permanently. Unless it's explicit, like a -save option. IMO.

I totally agree that the command line option should not alter the setting. this is not what I meant.
my point is, if the user opens the "network" window and then clicks "ok", they might expect the setting that is displayed to be saved.

[Tachikoma]

How so? If you use -g it overrides the gui just for one run. If you use -w it uses the wallet you specify but doesn't change the default. It's pretty normal for a cmd line option not to alter default configs. Until recent changes there wasn't even a saved config outside the wallet. I don't think that the cmd line options should be used to alter the saved config permanently. Unless it's explicit, like a -save option. IMO.

I totally agree that the command line option should not alter the setting. this is not what I meant.
my point is, if the user opens the "network" window and then clicks "ok", they might expect the setting that is displayed to be saved.

I think I'm misunderstanding the problem you lined out.

What happens right now is the following:

1. If you supply the --proxy argument and don't open the server window it's handled as a one time off parameter.
2. If you supply the --proxy argument and open the server window and press ok it gets saved to the config.

Which of those situations should be different?

The commit that disabled the Gui when no proxy option is selected can be found here, I would appreciate a review.

[ThomasV]

2. If you supply the --proxy argument and open the server window and press ok it gets saved to the config.

that.
it is not clear to me if an argument passed with --proxy should make it into the config and overwrite the previous setting when you press ok.
*if yes, then the network dialog will have a side effect that depends on the command line. that's not good.
*if not, then the network dialog does will not act consistently, but there is not warning for the user.

Note that the user will not always be the one who wrote the command line, so we cannot rely on saying "yeah, but the user knows it".
I believe that if --proxy is passed, then the network dialog should display the proxy, but modifying it should be disabled.