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

Good stuff ThomasV ... I sense you are not so 'retired' from Electrum as you indicated you might be, and this is not a bad thing.

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

why? are you not happy with the clock icons?
[/quote]
I haven't seen the clock icons yet. Just the previous check marks versions. No comment yet.

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?

I can help with that but someone would need to explain to me how exactly everything works. I can't read code but I do have a fairly decent understanding of programing logic.

I have a small patch that shows confirmation count as a tool tip instead of the trx id (which isn't very useful as a tool tip since you can't copy/paste from there). The tool tip was previously being used as a data holder between the list and the detail popup, so I also changed the code so the trx id is stored as a user data value in the list. That way the detail popup still has access to it.

I think it's useful to see the confirmation count easly but also it would good if the icon color changed according to count. eg. yellow for < 6 and normal for 6+ maybe.

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

No offense but why would you start an argument on the bitcoin-development mailing list about a client that has a specific thread on the bitcoin forums. I for one am on no mailing list simply because I hate even more mail then I already get. If you want a serious argument gmaxwell should have taken it here. Besides I think that you Thomas are the only one who can really answer those questions since you wrote all the cryptography bits anyway

Can anybody point me in the direction of some documentation about this SPV? I couldn't find anything substancial but it sounds interesting.

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 started implementing this a couple weeks back as part of my coin control branch but ran into some issue. So I backed it out and never got around to it again. However, in my history-filter branch it can be done manually by selecting an address and right clicking and choosing "Filter History". It will then show you any transactions using that address. You can multi-select a few addresses too. This branch is in my bkkcoins/electrum fork and not available in the main one. I'd suggest branch "merged-2" as it has all my combined feature additions. You're welcome to test it if you like - make sure you backup your wallet just in case. I have been using it daily here.

This may be true, I'm not enough of a crypto expert to say but I don't think it's the reason we generate new addresses for each transaction.

I think we do that for privacy as if you use the same address multiple times it increases the associations between transactions and therefore makes you more identifiable. If you paid multiple merchants with the same address then each of those merchants could possibly id you to a third party if they know who they dealt with / shipped to.

Likewise for merchants - if many of the customers paid to one address then those customers can now know that anyone else who paid to the address was buying a similar product or service. And in this case it's worse too because they wouldn't have to complete the deal, just request an address and then check the blockchain for who else paid there.

Incidentally the blockchain.info web site allows you to look up an address. It then gives you a "taint analysis" link that shows you how connected that address is to others. Taint in this case isn't "bad money" but rather visibly traceable usage.

Hello all, feature request and/or point-the-noob-in-the-right-direction request if this feature's already there somehow...

As I understand it, the Tx columns currently show how many *receiving* transactions the corresponding addresses have had. Could you add a column to show how many *spending* transactions they've had? Or even just a simple yes/no to the question 'has this address spent coins yet'?

I ask because I've been transferring coins between different wallet addresses, spending coins and then receiving more into the same address, turning off the 'send to change address' feature, generally doing all these things that I now come to understand are a slight security risk. I'd like a quick and easy way to see which addresses I've spent from, so that if there are any coins still in those addresses I can move them to a 'clean' address.


Yawny stuff follows:

... Just to check my understanding here: you've got private keys, public keys and addresses. They're related to each other by public-key=ecdsa(private-key) and address=ripemd-and-sha256-and-stuff(public-key). Both functions are currently irreversible (or 'computationally infeasible to reverse'). When an address receives money, only the address goes into the publicly-viewable blockchain. But when you spend money from an address, the public-key also goes in. You need the private key to spend money. So the security risk is that it's less secure to store coins in an address from which they've been spent before, than one which has never spent coins. 'Cos the former means everyone can now see the public key for that address, so to get the private key (and hence spend the remaining bitcoins) would require 'only' the ECDSA algorithm to have been broken, whereas to spend coins from an address which had never spent coins before would require ECDSA and RIPEMD and SHA256 to ALL have been broken. Right? So that's why we're supposed to keep generating new addresses for each transaction? And use change addresses?

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 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.

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.

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.

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


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 will try to do this later tonight if I get the time

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 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.

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.