[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[ThomasV]

Hi, I'm afraid I'm getting an incorrect global balance (0.050 while it should be 0.076) when connecting to any pruning servers. I also got the below error in the console a few times but I'm not sure if it's related to the issue:

this is fixed, see release 1.5.1 (thanks for the deseeded wallet)

[1714058220]

1714058220

[1714058220]

1714058220

[1714058220]

1714058220

[1714058220]

1714058220

[1714058220]

1714058220

[zebedee]

Thomas - I take it you can't reproduce the fact that priority flag is ignored? 

[Michael_S]

Electrum 1.5.1 on Ubuntu 10.04 LTS:
(I installed Electrum 1.5.1 directly over Electrum 0.58 - don't know if this is important)

(1)
When pressing the "Send" button I have to enter my wallet password and then I get this error message:
"local variable 'tx' referenced before assignment",
and the transaction is not executed.

I get the same behaviour irrespective of whether I enter the right or the wrong wallet password.

(2)
Moreover, in the "send" mask, the "?" button for the Fee says: "A suggested fee is automatically added to this field", but this is not the case, the field remains empty. With this behaviour I also do not understand the significance of the "Transaction Fee" entry in the general settings dialogue, if the Fee field is anyway empty by default in the send dialog.

[ThiagoCMC]

Hi!

 When I close Electrum 1.5.1 I'm getting:

Code:

Exception in thread Thread-2 (most likely raised during interpreter shutdown):Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 50, in apport_excepthook
    if not enabled():
TypeError: 'NoneType' object is not callable

Original exception was:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/electrum/gui_qt.py", line 83, in run
    self.emit(QtCore.SIGNAL('timersignal'))
AttributeError: 'NoneType' object has no attribute 'SIGNAL'
Exception in thread Thread-3 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 1182, in run
  File "/usr/local/lib/python2.7/dist-packages/electrum/interface.py", line 162, in get_response
  File "/usr/lib/python2.7/Queue.py", line 177, in get
  File "/usr/lib/python2.7/threading.py", line 258, in wait
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
  File "/usr/local/lib/python2.7/dist-packages/electrum/verifier.py", line 121, in run
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'Empty'

Best!
Thiago

[ThomasV]

Thomas - I take it you can't reproduce the fact that priority flag is ignored? 

I could reproduce it and I just pushed a fix.

[ThomasV]

Electrum 1.5.1 on Ubuntu 10.04 LTS:
(I installed Electrum 1.5.1 directly over Electrum 0.58 - don't know if this is important)

(1)
When pressing the "Send" button I have to enter my wallet password and then I get this error message:
"local variable 'tx' referenced before assignment",
and the transaction is not executed.

I get the same behaviour irrespective of whether I enter the right or the wrong wallet password.

(2)
Moreover, in the "send" mask, the "?" button for the Fee says: "A suggested fee is automatically added to this field", but this is not the case, the field remains empty. With this behaviour I also do not understand the significance of the "Transaction Fee" entry in the general settings dialogue, if the Fee field is anyway empty by default in the send dialog.

can you explain which GUI you are using, and whether you see this error message in a popup window or as a traceback? in the latter case, please post the traceback
the fee in the preference is the default fee per transaction input

edit: I believe this too is fixed now.

[ThomasV]

new bugfix release: version 1.5.2 is available.
please keep reporting the bugs you encounter.

[flatfly]

Nice bugfixes!

Here's another little issue, still in 1.5.2: It seems that after restoring a wallet from seed from a non-pruning server, the oldest transaction is wrongly labeled "Pruned transaction outputs"

[ThomasV]

Nice bugfixes!

Here's another little issue, still in 1.5.2: It seems that after restoring a wallet from seed from a non-pruning server, the oldest transaction is wrongly labeled "Pruned transaction outputs"

that's not a bug, it's a feature. see https://bitcointalk.org/index.php?topic=50936.msg1348988#msg1348988

[zebedee]

Thomas - I take it you can't reproduce the fact that priority flag is ignored? 

I could reproduce it and I just pushed a fix.

Confirmed fixed, thanks!

[flatfly]

Nice bugfixes!

Here's another little issue, still in 1.5.2: It seems that after restoring a wallet from seed from a non-pruning server, the oldest transaction is wrongly labeled "Pruned transaction outputs"

that's not a bug, it's a feature. see https://bitcointalk.org/index.php?topic=50936.msg1348988#msg1348988

Hmm... The post you linked to mentions restoring from a pruning server, while the issue I'm reporting appears when you recover from a non-pruning one. Unless I'm missing something?

[ThomasV]

Nice bugfixes!

Here's another little issue, still in 1.5.2: It seems that after restoring a wallet from seed from a non-pruning server, the oldest transaction is wrongly labeled "Pruned transaction outputs"

that's not a bug, it's a feature. see https://bitcointalk.org/index.php?topic=50936.msg1348988#msg1348988

Hmm... The post you linked to mentions restoring from a pruning server, while the issue I'm reporting appears when you recover from a non-pruning one. Unless I'm missing something?

oh sorry I misread. that's a bug then

[Michael_S]

Electrum 1.5.1 on Ubuntu 10.04 LTS:
(I installed Electrum 1.5.1 directly over Electrum 0.58 - don't know if this is important)

(1)
When pressing the "Send" button I have to enter my wallet password and then I get this error message:
"local variable 'tx' referenced before assignment",
and the transaction is not executed.

I get the same behaviour irrespective of whether I enter the right or the wrong wallet password.

(2)
Moreover, in the "send" mask, the "?" button for the Fee says: "A suggested fee is automatically added to this field", but this is not the case, the field remains empty. With this behaviour I also do not understand the significance of the "Transaction Fee" entry in the general settings dialogue, if the Fee field is anyway empty by default in the send dialog.

can you explain which GUI you are using, and whether you see this error message in a popup window or as a traceback? in the latter case, please post the traceback
the fee in the preference is the default fee per transaction input

edit: I believe this too is fixed now.

The error message appeared in popup window, both in classic and gtk GUI mode. --> confirmed: Both errors fixed in 1.5.3!

However, now there is another problem: I make a transaction, and after that a small popup window with title "Electrum" appears saying "Please wait...". This window seems to stay forever, and it remains even after I close the main Electrum window.

I don't know if this is important, but the following special settings were set before invoking that transaction (GUI was default=classic):
1) I froze all addreesses except one which I prioritized.
2) The transaction mentioned consisted of only one satoshi and the transaction fee was set to one satoshi as well.
3) "Use change address" was DE-selected in the program settings

Update: After rebooting the PC, I cannot reproduce this new "Please wait..." problem. Now transaction of 1 satoshi works (if tx fee is set 0.0001 instead of 1e-8 BTC). [update: I was able to reproduce this "Please wait..."-problem again when setting fee=0.00001 instead of 0.0001, so it seems to occur if fee is too low]

HOWEVER, now I am facing a "history tab update problem":
After doing the transaction, it does not show up in Electrum's history tab and the Electrum status line says "Synchronizing" all the time (although server connection was established when doing the transaction!), although at blockchain.info the transaction shows up instantly (within 1 or 2 seconds after I send the bitcoins in Electrum). After closing Electrum and re-starting Electrum, this latest transaction shows up immediately in the history tab.

I reproduced this "history-tab problem" four times, always with send amount =1e-8 BTC, fee=0.0001 BTC.

--> Update 2: I experienced this "history tab problem" with Electrum servers "electrum.bysh.me" and electrum.be, both of which are of type "full" in Electrum's server list. With the servers "ecdsa.org" and "electrum.novit.ro" (both of which are of type "pruning"), this "history tab problem" did not occur!

[Michael_S]

Here is another bug report: "Prioritization does not work as it should!" (Electrum 1.5.3 with classic GUI under Ubuntu 10.04 LTS)

Here is my description, it refers to this transaction:

http://blockchain.info/tx/be3eb9cbb06e2b35b35db278e9f4d1ae20240a95fc26f31336c1a8012078b5f5

In this transaction, 3 addresses are invoved (I mention only the first digit):
1D: source address (balance before transaction = 0.0050 BTC)
1F: source address (balance before transaction = 0.00029994 BTC)
1G: destination address

All addresses are in my wallet, they were configured as follows before I initiated the transaction:
1D = no label
1F = prioritized (and also labeled "change address" - don't know if this is important)
1G = frozen (but should be irrelevant because this is the destination address of my transaction)

[There was another (normal) address in my wallet that also had a balance > 0.0 BTC and that was frozen, and this address was not involved in this transaction at all, so I assume that the "freeze" feature works as desired, so I am not mentioning this address here any further.]

Moreover, I have told Electrum not to use change addresses by deselecting:
[ ] Use change address


Now, my transaction was: "Send 0.0020 BTC to address 1G"
The transaction had a fee of 0.0002 BTC, so the total transaction incl. fee was 0.0022 BTC.

I would have *expected* that address 1F (=the prioritized address) gets flushed completely, because its balance was much less than the total to be transferred, and that the remainder gets transferred from 1D to 1G.

So I would have expected an outcome like this:

• 1F (prioritized) = 0.00029994  -->  0.00000000 BTC (delta = -0.00029994 BTC)
• 1D (no label) = 0.0050  -->  0.00309994 BTC (delta = -0.00190006 BTC)
  (i.e. the change sent back to 1D because my client's setting was not to use any change address)
• 1G (destination) = 1G_old_balance + 0.0020 BTC

But instead, the transaction outcome was this:

• 1F (prioritized) = 0.00029994  -->  0.00309994 BTC (delta = +0.0028 BTC)
• 1D (no label) = 0.0050  -->  0.00000000 BTC (delta = -0.0050 BTC) (this is the non-prioritized address!!)
• 1G (destination) = 1G_old_balance + 0.0020 BTC

So, the behaviour was that the non-prioritized address (1D) was "flushed" and its change was sent to the (prioritized!) (change-)address 1F, although my Electrum client was configured not to use change addresses.

In general, my understanding is that by prioritizing an address I should flush it (i.e. new balance = 0 BTC) if the transaction size is big enough. However, here the opposite happened: After the transaction, the prioritized address' balance was higher than before the transaction.

It seems as if the Electrum client...
...ignored my setting "do not use change addresses"
...ignored the "prioritize" label (or used the given address as "prioritized change address" instead of "prioritized address to debit bitcoins from")

Hope this lengthy description was anyway clear and helpful.

[Michael_S]

[...]
Here is my description, it refers to this transaction:

http://blockchain.info/tx/be3eb9cbb06e2b35b35db278e9f4d1ae20240a95fc26f31336c1a8012078b5f5
[...]

Strange: after 5 hours, still not a single confirmation!

How can this be? The fee was 0.0002 BTC, so this should be sufficient to get a first confirmation after 10 or 20 minutes I thought.
The server I was connected to with Electrum was "electrum.novit.ro".

This is probably not a specific electrum client issue, but I have never experienced that long time without even a single confirmation when using the original bitcoin client... Any ideas? Is there the possibility that this transaction will never go through?

update: Now after around 6 hours some transactions start getting confirmed, and I see some transactions in the history that have still the "clock-icon" although when clicking "context menu-->details", I see that the number of confirmation is already six! Also changing back and forth between the other tabs keeps the "clock icon" being displayed in the history list. So I closed Electrum and restarted 1 second later, and now the transaction history list correctly indicates the hook-icons instead of the clock-icons.

Another thing:
In Electrum's History tab I right-click one of my recent transactions and select "Details". Then I see:

    Transaction Details

    Transaction ID:
    165cfc0d66580cdc3746ea1a43f3fa7560b8537259edec6d9eaf7294120408c0

    Status: -1 confirmations
    Amount sent:    -0.00000001
    Transaction fee:    -0.0001    
    Date: 2012-11-26 02:04

    Inputs:
    -1F3LZs6J6NHnRSm8ECLL7hVV9dNGtBZgob

    Outputs:
    -1F9KjbSH2kgagPrLmM7cVFLujHs7G4h5Q7
    -1F3LZs6J6NHnRSm8ECLL7hVV9dNGtBZgob

Also, there is no icon shown at all in that line (normally a clock-icon is shown for items with 1-6 confirmations, and a gear-icon for 0 confirmations).

At the same time, blockchain.info shows already 5 confirmations for this transaction. I assume that the "minus 1" and the missing icon is a bug in Electrum.

Now that I am writing this, blockchain.info has just changed from 5 to 6 confirmations for this transaction, and after re-starting Electrum it also shows the correct value "6" now instead of "-1" for this transaction.

[ThomasV]

So, the behaviour was that the non-prioritized address (1D) was "flushed" and its change was sent to the (prioritized!) (change-)address 1F, although my Electrum client was configured not to use change addresses.

In general, my understanding is that by prioritizing an address I should flush it (i.e. new balance = 0 BTC) if the transaction size is big enough. However, here the opposite happened: After the transaction, the prioritized address' balance was higher than before the transaction.

It seems as if the Electrum client...
...ignored my setting "do not use change addresses"
...ignored the "prioritize" label (or used the given address as "prioritized change address" instead of "prioritized address to debit bitcoins from")

Hope this lengthy description was anyway clear and helpful.

The change has to go somewhere. If you deselect 'use change addresses', it means that a new address will not be created for the change, so the change gets sent back to one of the input addresses used. (the first of the list)

[Michael_S]

So, the behaviour was that the non-prioritized address (1D) was "flushed" and its change was sent to the (prioritized!) (change-)address 1F, although my Electrum client was configured not to use change addresses.

In general, my understanding is that by prioritizing an address I should flush it (i.e. new balance = 0 BTC) if the transaction size is big enough. However, here the opposite happened: After the transaction, the prioritized address' balance was higher than before the transaction.

It seems as if the Electrum client...
...ignored my setting "do not use change addresses"
...ignored the "prioritize" label (or used the given address as "prioritized change address" instead of "prioritized address to debit bitcoins from")

Hope this lengthy description was anyway clear and helpful.

The change has to go somewhere. If you deselect 'use change addresses', it means that a new address will not be created for the change, so the change gets sent back to one of the input addresses used. (the first of the list)

I see, so this works as designed and is not a bug in principle. Then my concrete suggestion would be to change the behaviour as follows, if this is easily possible, to make the behaviour more similar to what would be expected by the user:
If 'use change address' is deselected and the number of transmit addresses of a transaction is > 1, then the change of this transaction goes to the first address in the list that satisfies two conditions:
1) it is NOT prioritized (no "P")
2) it is labelled as change address ("C")
If none of the involved addresses fulfills both conditions, then use the first address in the list that fulfills only condition 1.
If no involved address fulfills condition 1, then use the first address that fulfills only conditon 2.
If no involved address fulfills condition 2 either, then just use the first address in the list.

[ThomasV]

So, the behaviour was that the non-prioritized address (1D) was "flushed" and its change was sent to the (prioritized!) (change-)address 1F, although my Electrum client was configured not to use change addresses.

In general, my understanding is that by prioritizing an address I should flush it (i.e. new balance = 0 BTC) if the transaction size is big enough. However, here the opposite happened: After the transaction, the prioritized address' balance was higher than before the transaction.

It seems as if the Electrum client...
...ignored my setting "do not use change addresses"
...ignored the "prioritize" label (or used the given address as "prioritized change address" instead of "prioritized address to debit bitcoins from")

Hope this lengthy description was anyway clear and helpful.

The change has to go somewhere. If you deselect 'use change addresses', it means that a new address will not be created for the change, so the change gets sent back to one of the input addresses used. (the first of the list)

I see, so this works as designed and is not a bug in principle. Then my concrete suggestion would be to change the behaviour as follows, if this is easily possible, to make the behaviour more similar to what would be expected by the user:
If 'use change address' is deselected and the number of transmit addresses of a transaction is > 1, then the change of this transaction goes to the first address in the list that satisfies two conditions:
1) it is NOT prioritized (no "P")
2) it is labelled as change address ("C")
If none of the involved addresses fulfills both conditions, then use the first address in the list that fulfills only condition 1.
If no involved address fulfills condition 1, then use the first address that fulfills only conditon 2.
If no involved address fulfills condition 2 either, then just use the first address in the list.

all right, I made that change here: https://github.com/spesmilo/electrum/commit/e87ed44f8494e0a665ff917bda8325d64b0f4c4b
it will send change to the last address of the list of inputs, so it will not be prioritized if there are unprioritized inputs

[BRules]

ok, I'm on windows xp and this is my installation steps:

downloaded pyton 3.3 and installed,
downloaded pyqt 4.9.5 for python 3.3 and installed
downloaded electrum 1.5.3, extracted and type "python electrum" on cmd and I'm getting:

Error: python-ecdsa does not seem to be installed. Try 'sudo pip install ecdsa'

am I missing anything?

[BRules]

looks like I'm missing something, on the electrum site has:

Install Electrum-1.5.3.zip

What exactly this mean? how am I supposed to intall a zip file?