[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[duncant]

Hi! I have 5 bugs to report:


1) I get the following error when running "electrum addresses -k" with imported keys (and an unencrypted wallet). I strongly suspect that this is due to how tags are stored with imported keys. It manages to print all the keys that do not have tags until it reaches one that does. Then the error occurs. Furthermore, if I manually remove the tagged key from my wallet file, this error does not occur.

Code:

Traceback (most recent call last):
  File "./electrum", line 364, in <module>
    addr += ':' + str(wallet.get_private_key_base58(addr, password))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/electrum/wallet.py", line 375, in get_private_key_base58
    pk = self.get_private_key(address, password)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/electrum/wallet.py", line 386, in get_private_key
    secexp = int( b.encode('hex'), 16)
AttributeError: 'bool' object has no attribute 'encode'

2) When my wallet is encrypted, I experience the same problem as flatfly. I have done nothing nonstandard with my wallet file; I just imported a bunch of keys and tagged a few. (perhaps this is related to the above error?)


3) Additionally, I get this error when changing my password (which appears to work anyway, despite the error):

Code:

Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/electrum/gui_qt.py", line 702, in <lambda>
    sb.addPermanentWidget( StatusBarButton( QIcon(":icons/lock.png"), "Password", lambda: self.change_password_dialog(self.wallet, self) ) )
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/electrum/gui_qt.py", line 941, in change_password_dialog
    wallet.update_password(seed, new_password)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/electrum/wallet.py", line 856, in update_password
    b = self.pw_decode(a, password)
NameError: global name 'password' is not defined

These last two are the important ones
4) When you "electrum -w <wallet> import <pub>:<priv>" followed by "electrum -w <wallet> deseed" then "electrum -w <wallet> addresses -k", <priv> is still displayed. I'm not sure if this is expected behavior, but at the very least there should be a caveat that offline wallets are currently incompatible with imported keys.


5) The secret keys of imported keys appear in plaintext in the wallet file when the wallet file is encrypted.


Thank you for the time you've put in creating this awesome software.

[1714101548]

1714101548

[1714101548]

1714101548

[1714101548]

1714101548

[1714101548]

1714101548

[1714101548]

1714101548

[ThomasV]

Hi! I have 5 bugs to report [...]

trying to reproduce those...
just to make sure: what is your OS, version of python and version of Electrum?

[duncant]

Mac OS X 10.7.4, Python 2.7.3, The latest from gitorious (I did a git pull before reporting these bugs, just to make sure)

[ThomasV]

other question: did you use deseed/reseed? did you change your password?
before or after the import?

I am trying to reproduce it but no success so far

[ThomasV]

ok, I found it.
things go wrong if you import keys and later change your password using the gui

[duncant]

To reproduce (3):
encrypt wallet
import key
decrypt wallet/change password

To reproduce (1):
encrypt wallet
import key
tag imported key
decrypt wallet
"electrum -w <wallet> addresses -k"


I'm working on replicating the other bugs from scratch, I'll post again when I've done it.

[duncant]

....and I see you've already done that

[duncant]

Additional, minor bug:
"electrum -w <wallet> create" and "electrum -w <wallet> restore" prompts for a password to encrypt your wallet, but appears not to actually encrypt the wallet if the password is supplied.

[ThomasV]

I commited two fixes.
let me know if there are still problems.

[ThomasV]

Additional, minor bug:
"electrum -w <wallet> create" and "electrum -w <wallet> restore" prompts for a password to encrypt your wallet, but appears not to actually encrypt the wallet if the password is supplied.

that too (third commit)

[flatfly]

I commited two fixes.
let me know if there are still problems.

Thanks, things look good to me so far.

[flatfly]

A separate issue: the wallet restoration process often appears to stall at the very last address.

In those cases, I then have to close the 'restore' progress dialog manually, then the main window opens normally, but, synchronizing then takes a long time (minutes) - is it possible to show some kind of progress (in %, or blocks) in the status bar? Just so the user knows if the program is actually doing something or not.

[ThomasV]

A separate issue: the wallet restoration process often appears to stall at the very last address.

In those cases, I then have to close the 'restore' progress dialog manually, then the main window opens normally, but, synchronizing then takes a long time (minutes) -

the client has to find a gap with 5 empty addresses in order to know that it arrived at the 'last' address.

in addition, it downloads address statuses and histories separately.
if you have very long histories and a slow connection, it can take some extra time to request and download them.
this extra time will belong to the progress dialog unless you close it.

is it possible to show some kind of progress (in %, or blocks) in the status bar? Just so the user knows if the program is actually doing something or not.

there's no way to know in advance how much time is remaining, but the client could display kilobytes downloaded

[ThomasV]

I released version 0.49b with the above fixes.

changelog:
* fix bug caused by interaction between imported keys and encryption

[flatfly]

I released version 0.49b with the above fixes.

changelog:
* fix bug caused by interaction between imported keys and encryption

Great! My Win stand-alone build is now available too. (link in my signature)
SHA-1: 11ade02b8022efcefd2f908381a3e8edfa4faccb

[flatfly]

...
way to know in advance how much time is remaining, but the client could display kilobytes downloaded

Yes, this would be good as well - the little touches like that definitely help the end-user experience IMHO

[ThomasV]

...
way to know in advance how much time is remaining, but the client could display kilobytes downloaded

Yes, this would be good as well - the little touches like that definitely help the end-user experience IMHO

ok, I added it to the qt dialog. see version 0.49c.

[flatfly]

...
way to know in advance how much time is remaining, but the client could display kilobytes downloaded

Yes, this would be good as well - the little touches like that definitely help the end-user experience IMHO

ok, I added it to the qt dialog

Thanks. I just tested it, and now I can see that when the process stalls
at the last address (115 for me) there is no more data received, and I have to
manually close the window. (First, I tried to wait for 3 minutes but nothing else
was happening)
 
For your info, I currently have about 250 entries/transactions in my history.

Screenshot:

[ThomasV]

Thanks. I just tested it, and now I can see that when the process stalls
at the last address (115 for me) there is no more data received, and I have to
manually close the window. (First, I tried to wait for 3 minutes but nothing else
was happening)
 
For your info, I currently have about 250 entries/transactions in my history.

ok, if it stalls then there might be another bug.
it could be related to the large size of your wallet;

right after you close the window, does the client display "synchronizing", or is it immediately ready?

[flatfly]

Thanks. I just tested it, and now I can see that when the process stalls
at the last address (115 for me) there is no more data received, and I have to
manually close the window. (First, I tried to wait for 3 minutes but nothing else
was happening)
 
For your info, I currently have about 250 entries/transactions in my history.

ok, if it stalls then there might be another bug.
it could be related to the large size of your wallet;

right after you close the window, does the client display "synchronizing", or is it immediately ready?

It displays "synchronizing", but it seems that I do have to kill and restart it before it actually synchronizes.
My wallet file is approximately 500KB.

EDIT: I tried again, this time all went fine with no hiccups, and I found out that I actually have
152 addresses, not 115. So for some reason, it sometimes hangs at or around 115 for me.