merged, thanks.

I pushed SSL support to the repo; it will be used by the next release of the client.
if you have a server, please upgrade 

thank you for the feedback



Several users requested this. I am not convinced that the benefits outweight the cost (increased complexity for the gui),
so my opinion is that it is fine to open several wallets simultaneously (I admit that will not let you merge their histories)

OTOH I will be glad to merge it, if someone comes up with an implementation that is clean and remains optional.
For example the gui could display multi-wallet features only if several wallets are passed with the -w option



it really depends on how it is implemented, but I don't see how to do this without making gui terribly complex.


I agree, I will try to fix those.

I agree

yes, the current code does this.

my version is in the repo, (scripts/servers) but it does not exactly what you want for this website:
it does not queries all servers from irc, only the hardcoded list.

well, it's a pity there hasn't been any release since then.
I will take over for the next release (1.1).
it should be ready in less than a week.

how did that arise?

Please note that private messages encryption is not activated by default when you first login.
You have to visit Settings->Privacy and enter a passphrase. Your encryption keypairs will be derived from it.
The passphrase is not sent to the server, it is stored locally (cookie)

do:
git pull
and then rebuild icons:
pyrcc4 icons.qrc -o lib/icons_rc.py

nice! using it as a data holder was indeed a bit dirty.
I think we could have the numver of confirmations in the icon's tooltip, and add a new tooltip with the tx id, for the 'description' column.

why? are you not happy with the clock icons?

https://en.bitcoin.it/wiki/Thin_Client_Security

A thread about Electrum's security model was started here a week ago:

http://sourceforge.net/mailarchive/forum.php?thread_name=CANEZrP3Ei8tU%3Dr_gp5K1fPGFe4gvX02gp%2ByuQRi0cwHhLLTe8g%40mail.gmail.com&forum_name=bitcoin-development

I agree with gmaxwell about the technical arguments presented in that thread. Electrum is susceptible to some attacks, and we should do what we can to improve it. However, I also think that when discussing security, it is important to also look at what actually happens with real users. Lots of users reported that they have lost their coins with bitcoin-qt, because they did not properly backup their wallet. This is a big issue, IMO, bigger than the possible attacks mentioned in that thread (which remain theoretical so far, as far as electrum is concerned). For some developers this does not seem to be a real issue, because users should be educated, so that if users lose their coins it is their fault. I disagree on that.

This does not mean we should not listen to criticism. I believe we should try to improve Electrum where it is possible.
gmaxwell suggested the following improvements, and I will work on them:
 - adding confirmation icons to the gui (I did it right away, using an old pull request made by Tachikoma)
 - adding SSL to the protocol. This should be easy, and can be targeted soon, maybe in the next (1.1) release.
 - adding SPV (simple payment verification) to the protocol. This will take more time, I guess we should add it in the 2.0 release.
 - adding a better explanation of the security model to the website. he is willing to help me on that.

One problem that is mentioned in the thread is the lack of response from Electrum developers. I was not aware of the existence of that thread since I unregistered from the bitcoin-dev ML; I prefer to use bitcointalk.org for discussions about Electrum, because I think messages posted here reach more people. In addition, the messages in that thread were forwarded to the 'official' Electrum email support address, which I believe is genjix's address. And genjix has been away for quite a while now. This is, IMO, a big issue. It caused gmaxwell to suggest that we are "unwilling to disclose" the limitations of the software.

I have recently performed a large scale refactoring of the client code.
The purpose of this change was to introduce a new abstraction level between application settings and their storage on disk.
This was a much needed change, and I apologize if it broke modifications you were working on.

Each component of the application (wallet, interface, gui) now handles its settings separately.

Settings can be passed to the application using four different sources, that have different priorities:

1. the wallet file (read&write)
2. a system wide configuration file (overrides wallet file, read-only). (it is located in /etc/electrum.conf for unix)
3. a user-defined configuration file (overrides system configuration and wallet file, read&write). (it is located in ~/.electrum/electrum.conf. Perhaps ~/.electrum.conf would be better?)
4. the command line (overrides everything, read-only)

A sample configuration file is provided in the repo. It is human-editable and uses the ConfigParser syntax.
When a setting is present in the command line or in the system configuration file, it is read-only, and the corresponding Qt GUI modification widget is disabled.
In addition, a warning is issued if the application attempts to modify a read-only setting.

python scripts that use electrum are also simplified by this change. It is now possible to call electrum.Interface() with no parameters at all;
in that case, the constructor uses configuration files in order to know which server it should use.

I believe we should try to prepare a new release in the coming weeks.

I would try to rebuild of the abe database from scratch. (I know, it is slow...)

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.

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.

thanks.

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.

that would be nice. thanks!

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.

looks safe to me. thanks for the patch!

I just added a new script to Electrum, named "merchant.py"

It is a daemon that manages payments for a web server. It creates Bitcoin addresses using a master public key (so you do not leave your private keys on the server), detects when payments are received and notifies your web application.

The workflow goes like this:

 - the server sends a request to the daemon via POST. the request contains an ID, an amount to be paid, an expiration period.
 - the daemon answers with a bitcoin address, where the customer needs to send the coins.
 - later, the daemon will send a POST to the webserver, to notify that payment has been received OR that the request has expired

This is, IMO, as simple as it can get.

Since addresses are generated using an Electrum master public key, it is possible to visualize payments in the Electrum client; you will, however, need to manually adjust your "gap limit".
There are a few unfinished things, such as requesting a given number of confirmations, but I thought it would be ok to publish it now.

The script is being used at https://ecdsa.org

please go ahead, if you feel like it