[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[BkkCoins]

This happened to me.  What do you mean by visiting a full server?  How is this done?
I am a noob.  Please and thank you.

Should I have any concerns updating to 1.7.3?

Some of the servers in the list are "full" servers. I'm not sure how you know now as they used to have an 'F' next to their name and now they don't. But if you try a few randomly you'll likely hit a full one and get updated fully.

[1714225579]

1714225579

[1714225579]

1714225579

[nioc]

Thanks I have my hx back.

I am still on 1.7.2 and all the servers were listed as F including the one I was on.  I chose another one but it didn't go to that server but a different one.  Now I have a list of servers that are noted F or P.  The original server I was connected to and the one I tried to change to are not on that list.  I wonder how many servers there are.

[BkkCoins]

The original server I was connected to and the one I tried to change to are not on that list.  I wonder how many servers there are.

The servers enumerate themselves via the #electrum irc channel with E_* user names. So if you go there you'll see them listed as users and their user info has details that get queried by the client.

[Michael_S]

Hello Thomas,

Here are some 1.7.3 specific bug reports (I have to revert back to 1.7.2 because there are too many regressions in 1.7.3):

I want to share some test results: I discovered the following bugs up to now, all are specific to 1.7.3 (i.e. works flawlessly in 1.7.2):

(1) In the default GUI, when using the new account selector in the "receive" tab, the "Addresses" column collapses in width to a very narrow width - I have to drag the column width back to normal width with the mouse. 100% reproducible.

I have that bug too, but I cannot trigger in in a reproducible way.
I think it has been there for a long time, and it is not correlated with the account selector as far as I can see.
it has been introduced with the column widths.

(2) Command line "electrum mktx": When i have "use change address" activated in the GUI (and then close the GUI to memorize the new setting, and then make the command line "mktx"), my change is still going to another address, not to one of my change addresses (I did not check if it also happens when initiating the transactions from the GUI). Again only in 1.7.3. In 1.7.2 it works as expected.

are you sure?
recent versions of Electrum sometimes reuse the same change addresse several times, until the previous transactions at the address have 3 confirmations.
this is in order to avoid the creation of gaps in the sequence of change addresses, during blockchain forks.

(3) Command line: The following command is executed correctly in 1.7.2, but not in 1.7.3:
electrum mktx -w electrum_deseeded_online_wallet.dat  -F 16u48JjWLvLX1qnWt1Dm9WvzYP84z1b47P 1KDF6wN6Um1LQDjFoi8vGjcLKph6RGfCfV 0.009

Background: the FROM address (-F switch) has a balance of 0.0097, and tx fee is 0.0001. the target address is one from my wallet.

The error message that I get is:
Error: unhashable type: 'list'

When I omit the FROM address (the "-F 1xxxxxx" field, bold letter above), it works also in 1.7.3.

indeed. I will fix that.

(4) Sometimes I get errors when starting electrum in 1.7.3. After second try, it works. Only observed in 1.7.3, never in 1.7.2. Sporadic, but occured 3 to 4 times already this evening.

this is vague...

Hence, overall, version 1.7.3 seems to be pretty "buggy" at the moment.


My system is ubuntu 12.04 with "python 2.7.3 from Aug  1 2012, 05:16:07".
I used an own wallet file, not the default "electrum.dat", for all these trys, and this own wallet was a deseeded wallet, because I used it in the context of creating offline transactions (to be signed on an Offline PC).

thanks for the comments.
note that with 1.7.3 you can load and sign offline transactions from the gui

Hello Thomas,
I am going to try to reproduce it again on another PC having Phyton 2.6 instead of 2.7... hope I will find some time. For now I can only say that I am quite sure that all my above observations are correct...

About the offline transactions - yes, I have seen that it is also supported in the GUI now, this is very useful! I have anyway written a collection of (extremely easy-to-use) bash scripts for exactly this purpose - I started that before Electrum had this GUI function, and I finished it yesterday. I will announce it in a separate post (or maybe I should rather open a new thread...(?) [update: opened new thread here]).

I am going to setup my offline PC (=EeePC on Ubuntu 12.04 (Python 2.7)) in the next days, the corresponding online PC will run Ubuntu 10.04 (Python 2.6). After having done this, I will hopefully do some more testing.

[Michael_S]

Hello Thomas,

finally, here are some further and more consolidated infos of my testing results of 1.7.3 (the major bugs are (2) and (6) below):

Hello Thomas,

Here are some 1.7.3 specific bug reports (I have to revert back to 1.7.2 because there are too many regressions in 1.7.3):

I want to share some test results: I discovered the following bugs up to now, all are specific to 1.7.3 (i.e. works flawlessly in 1.7.2):

(1) In the default GUI, when using the new account selector in the "receive" tab, the "Addresses" column collapses in width to a very narrow width - I have to drag the column width back to normal width with the mouse. 100% reproducible.

I have that bug too, but I cannot trigger in in a reproducible way.
I think it has been there for a long time, and it is not correlated with the account selector as far as I can see.
it has been introduced with the column widths.

Well, if I start up the default GUI a few times, it happens quite soon. Both on Ubuntu 10.04 (Python 2.6.5) and Ubuntu 12.04 (Phython 2.7.3), but I have to correct myself, it is not 100% immediately reproducible. Typically I click the tabs back end forth a few times, then click the "Receive" tab, then when clicking the account selector back and forth a few times, it suddenly happens ("happens" means that the address column becomes very narrow and I have to re-adjust it manually). If it happens once, then it happens again 100% whenever I use the account selector. When I close the GUI and restart it, the error may be there again (most cases), or it is just gone...

(2) Command line "electrum mktx": When i have "use change address" activated in the GUI (and then close the GUI to memorize the new setting, and then make the command line "mktx"), my change is still going to another address, not to one of my change addresses (I did not check if it also happens when initiating the transactions from the GUI). Again only in 1.7.3. In 1.7.2 it works as expected.

are you sure?
recent versions of Electrum sometimes reuse the same change addresse several times, until the previous transactions at the address have 3 confirmations.
this is in order to avoid the creation of gaps in the sequence of change addresses, during blockchain forks.

100% sure now! On my Offline PC I made a wallet as follows: gap limit=5=default, and 6 imported private keys. One of the imported keys has a balance of ca. 0.39 BTC, all the other addresses have never been used. What I do is this:

1.) I deseed the wallet on the Offline PC and import it into my Online PC. The wallet name in both PCs is not the default one but an own one using the "-w" option.
Note: I have NOT prioritized or frozen any addresses.

2.) Then, on the Online PC, I create the following unsigned transaction: I transfer 0.1 BTC to the 3rd of my own deterministic addresses of my wallet (I don't know if this is important, I assume it would be the same outcome if I used a foreign address, just mentioning this in case it might be relevant...). tx_fee=default=0.0002 BTC.
The command is essentially this one (using bash syntax):
electrum mktx -w $walletfile $targetaddress $amount > $outputfile

2.a,b,c,d) I do the step 2 above four times:
  a) With electrum 1.7.3, after having set "use change address=no" in the GUI and having closed the GUI.
  b) With electrum 1.7.2, after having set "use change address=no" in the GUI and having closed the GUI.
  c) With electrum 1.7.3, after having set "use change address=yes" in the GUI and having closed the GUI.
  d) With electrum 1.7.2, after having set "use change address=yes" in the GUI and having closed the GUI.

The operations (a), (b), and (d) are correct. However, for (c) the result is the same as for (a) and (b), i.e. the change is sent back to the sending address and is not, like in (d) sent to the 1st change addresses of my wallet.

Update: I also checked what happens when I generate the unsigned transaction file via the GUI: Outcome: The bug of 1.7.3 is exactly the same!!! So it is not something specific to the command line mode.


Here are further bugs:
(5) (Both in 1.7.2 and 1.7.3) In the settings, the pulldown menu for choice of the fiat currency is often not usable, the pull-down menu is just missing, it just displays "None", and I cannot select any currency, the list is just not showing up. Sometimes it helps clicking the tabs back and forth and trying again opening the settings window. Sometimes it helps closing the GUI and starting again. After many such tries eventually I succeed in setting the fiat currency.

(6) Only version 1.7.3 (works perfectly in 1.7.2) - another MAJOR bug: Creation of a new wallet via the command line fails!
Command: electrum -w /home/michael/Dokumente/testbla.dat create

Here is the error message:

Code:

michael@michaels-EeePC:~/Dokumente/client_Electrum$ electrum -w /home/michael/Dokumente/testbla.dat create
Password (hit return if you do not wish to encrypt your wallet):
Confirm: 
server (default:electrum.no-ip.org):
port (default:50002):
protocol [t=tcp;h=http;n=native] (default:s):
fee (default:0.0002):
gap limit (default 5):
Traceback (most recent call last):
  File "/usr/local/bin/electrum", line 272, in <module>
    wallet.synchronize() # there is no wallet thread 
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 394, in synchronize
    new += self.synchronize_account(account)
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 387, in synchronize_account
    new += self.synchronize_sequence(account, 0)
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 376, in synchronize_sequence
    new_addresses.append( self.create_new_address(account, for_change) )
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 298, in create_new_address
    address = self.get_new_address( account, for_change, n)
  File "/usr/local/lib/python2.7/dist-packages/electrum/wallet.py", line 306, in get_new_address
    return self.sequences[account].get_address((for_change, n))
  File "/usr/local/lib/python2.7/dist-packages/electrum/bitcoin.py", line 443, in get_address
    pubkey = self.get_pubkey(sequence)
  File "/usr/local/lib/python2.7/dist-packages/electrum/bitcoin.py", line 459, in get_pubkey
    z = self.get_sequence(sequence, mpk)
  File "/usr/local/lib/python2.7/dist-packages/electrum/bitcoin.py", line 439, in get_sequence
    return string_to_number( Hash( "%d:%d:"%(n,for_change) + mpk.decode('hex') ) )
AttributeError: 'NoneType' object has no attribute 'decode'
michael@michaels-EeePC:~/Dokumente/client_Electrum$

Update: The simpler command electrum create fails as well with v.1.7.3.

PS: all the bugs occur with both Python 2.6.5 (ubuntu 10.04) and 2.7.3 (ubuntu 12.04)

[pyra-proxy]

Is the lite coin version of elect rum updated and maintained here as well?  Also, can a single elect rum client manage both bit coin and lite coin wallets simultaneously... maybe even with the same seed?

[Tachikoma]

Is the lite coin version of elect rum updated and maintained here as well?  Also, can a single elect rum client manage both bit coin and lite coin wallets simultaneously... maybe even with the same seed?

No space is needed, it's Electrum.

Electrum litecoin is an unofficial fork which is currently not maintained by the forker (Coblee).

[pyra-proxy]

Is the lite coin version of elect rum updated and maintained here as well?  Also, can a single elect rum client manage both bit coin and lite coin wallets simultaneously... maybe even with the same seed?

No space is needed, it's Electrum.

Electrum litecoin is an unofficial fork which is currently not maintained by forker (Coblee).

Thanks and I hate mobile auto-correct too :-)

[inaltoasinistra]

Hi folks!
(I love this client)

I have a question about the behaviour of change/prioritize addresses.
I had some bitcoins in 3 imported addresses and some in a Electron address; i wanted to use the coins in imported addresses, so I prioritize them and made the payment. There were some returned bitcoins and they were put in an imported address instead of a change address. Why? Is it because the imported address was prioritize? Is it possible avoid this?

Thanks.
Sorry my orrible English.

[ThomasV]

Hi folks!
(I love this client)

I have a question about the behaviour of change/prioritize addresses.
I had some bitcoins in 3 imported addresses and some in a Electron address; i wanted to use the coins in imported addresses, so I prioritize them and made the payment. There were some returned bitcoins and they were put in an imported address instead of a change address. Why? Is it because the imported address was prioritize? Is it possible avoid this?

Thanks.
Sorry my orrible English.

Previously, a user lost some coins because he expected change from an imported address to be sent back to the same imported address
(he deleted his wallet and seed, but the change was sent to an address derived from the seed)
I changed this in order to prevent that from happening again.

[Michael_S]

Hi folks!
(I love this client)

Me too, definitely! (Else I wouldn't use it and spend much time for testing and reporting my experience and trying to contribute my part in making it more usable for the "normal user")

I have a question about the behaviour of change/prioritize addresses.
I had some bitcoins in 3 imported addresses and some in a Electron address; i wanted to use the coins in imported addresses, so I prioritize them and made the payment. There were some returned bitcoins and they were put in an imported address instead of a change address. Why? Is it because the imported address was prioritize? Is it possible avoid this?

Thanks.
Sorry my orrible English.

Previously, a user lost some coins because he expected change from an imported address to be sent back to the same imported address
(he deleted his wallet and seed, but the change was sent to an address derived from the seed)
I changed this in order to prevent that from happening again.

That user should have just set "use change addresses=no" in the program settings, instead of requesting unlogical changes of the program's behaviour.

So this unlogical new behaviour in 1.7.3 probably explains the bug that I reported as bug #(2) in my post #1470 for Electrum 1.7.3:

On my Offline PC I made a wallet as follows: gap limit=5=default, and 6 imported private keys. One of the imported keys has a balance of ca. 0.39 BTC, all the other addresses have never been used. What I do is this:

1.) I deseed the wallet on the Offline PC and import it into my Online PC. The wallet name in both PCs is not the default one but an own one using the "-w" option.
Note: I have NOT prioritized or frozen any addresses.

2.) Then, on the Online PC, I create the following unsigned transaction: I transfer 0.1 BTC to the 3rd of my own deterministic addresses of my wallet (I don't know if this is important, I assume it would be the same outcome if I used a foreign address, just mentioning this in case it might be relevant...). tx_fee=default=0.0002 BTC.
The command is essentially this one (using bash syntax):
electrum mktx -w $walletfile $targetaddress $amount > $outputfile

2.a,b,c,d) I do the step 2 above four times:
  a) With electrum 1.7.3, after having set "use change address=no" in the GUI and having closed the GUI.
  b) With electrum 1.7.2, after having set "use change address=no" in the GUI and having closed the GUI.
  c) With electrum 1.7.3, after having set "use change address=yes" in the GUI and having closed the GUI.
  d) With electrum 1.7.2, after having set "use change address=yes" in the GUI and having closed the GUI.

The operations (a), (b), and (d) are correct. However, for (c) the result is the same as for (a) and (b), i.e. the change is sent back to the sending address and is not, like in (d) sent to the 1st change addresses of my wallet.

Update: I also checked what happens when I generate the unsigned transaction file via the GUI: Outcome: The bug of 1.7.3 is exactly the same!!! So it is not something specific to the command line mode.

As I understand Thomas now, this behaviour also occurs in normal mode (as reported by inaltoasinistra), and not only in "offline transaction mode" with two PCs, that I was using.

If I understand Thomas correctly, since version 1.7.3 change addresses are only used for transactions involving at least one non-imported address. However, if transactions involve only imported addresses, then the change is always sent back to one of them, i.e. for such transactions the Electrum client 1.7.3 behaves like for the setting "use change address=no", even if actually the user has set "use change address=yes."

I would propose to at least explain this in the help dialog, because this behaviour is all but self-explanatory (this behaviour came as a surprise to both inaltoasinistra and me, independently).

But actually I would rather propose to revert to 1.7.2-like behaviour: Honestly, I do not understand that other user's request that motivated this change in 1.7.3. That user may equally well have deleted the private keys of this imported addresses (instead of the seed of his deterministic wallet), in which case he may have complained about just the opposite behaviour!

So generally, as a normal and reasonably thinking user, when I set "use change address=yes" in the program's setting, I would, and should, expect that exactly this happens (as it did until version 1.7.2), namely that the change is actually sent to the change addresses! If a user does not properly back up his wallet, he should not blame the program! And he should not request unlogical program changes. In fact, Electrum 1.7.2 behaved fully correctly, logically, and fully compliant to the program settings!

So I would propose, in all due respect to that user (whom I do not know), that Electrum behaviour returns back to 1.7.2-like behaviour, with respect to how it uses change addresses acc. to program settings. Otherwise, Electrum behaviour will become non-transparent and unforeseeable, and this is much worse, and more of a risk that may lead to users loosing their Bitcoins, because the client behaves differently to what one would reasonably expect.

Alternatively, I could imagine program settings with these selection boxes, then everyone will be happy:
(1) (x) Use change addresses
(2)     (x) Do NOT use change addresses for transactions only involving imported addresses
(line (2) could be selected by default (to mimic v.1.7.3's behaviour) and should be greyed-out if box (1) is deselected)

Kind regards,
Michael

[zebedee]

Michael - I agree the behaviour should be consistent, and not an attempt to hack around users' mistakes - users will always find a way to screw up, and the answer isn't to make the behaviour more convoluted.

[pyra-proxy]

Michael - I agree the behaviour should be consistent, and not an attempt to hack around users' mistakes - users will always find a way to screw up, and the answer isn't to make the behaviour more convoluted.

A little convoluted could have fixed this better I think, perhaps a setting on the window that detects when sending coins from an imported key and allow the user to spell out if they want the behavior that change is returned to imported key or to electrum seed keys.

[BkkCoins]

Michael - I agree the behaviour should be consistent, and not an attempt to hack around users' mistakes - users will always find a way to screw up, and the answer isn't to make the behaviour more convoluted.

A little convoluted could have fixed this better I think, perhaps a setting on the window that detects when sending coins from an imported key and allow the user to spell out if they want the behavior that change is returned to imported key or to electrum seed keys.

Or why not a change-address selection for all send transactions. Remember the last used value and you don't even need a default setting. Then whenever a send is made it's right there in the face what will happen to change - back to same, back to new, back to a selected address from this list. ie. one drop down box with all the choices. This way nothing is hidden or left to chance - if it goes to the wrong place it's user error.

[pyra-proxy]

Michael - I agree the behaviour should be consistent, and not an attempt to hack around users' mistakes - users will always find a way to screw up, and the answer isn't to make the behaviour more convoluted.

A little convoluted could have fixed this better I think, perhaps a setting on the window that detects when sending coins from an imported key and allow the user to spell out if they want the behavior that change is returned to imported key or to electrum seed keys.

Or why not a change-address selection for all send transactions. Remember the last used value and you don't even need a default setting. Then whenever a send is made it's right there in the face what will happen to change - back to same, back to new, back to a selected address from this list. ie. one drop down box with all the choices. This way nothing is hidden or left to chance 0 if it goes to the wrong place it's user error.

+1 this version of the idea.

[ThomasV]

as you may have noticed, in 1.7.3 imported addresses are in a separate account.
in future versions users will have the possibility to create several seed generated accounts, with change addresses.

a general principle that defines accounts is that Electrum should not mix addresses from different accounts when doing a transaction.
so when it uses account A, it will not send the change to account B.

to keep this consistent, if you use the imported addresses, the change will go to imported addresses.

[Michael_S]

Oh I see - this makes sense then, and that's nice and useful in fact.

PS: reminder for 1.7.3: On the command line, "electrum create" or "electrum -w mywalletfile.dat create" does not work (contrary to 1.7.2)

[Bakemono]

Hello and good job with electrum  

I have a couple of question though.

I m reading from electrum.org

Ubiquitous: You can use the same wallet on different computers, it will auto-synchronize.

How do you achieve the auto-synchronization?With the -w part or i am missing something here?

Also what is the master public key and why do i need to be aware of it.

Thank you.

[btcven]

Hello and good job with electrum  

I have a couple of question though.

I m reading from electrum.org

Ubiquitous: You can use the same wallet on different computers, it will auto-synchronize.

How do you achieve the auto-synchronization?With the -w part or i am missing something here?

Also what is the master public key and why do i need to be aware of it.

Thank you.

Your wallets are synchronized because transactions go trough the Electrum Servers, so all your Electrum client instances carrying your seed are synced trough the Servers.

The MPK is used to create seedless wallets, so you can have a wallet without its seed (private keys) and only with your public addresses (almost like a watch-only wallet). With that seedless wallet you can see the transactions and create new receiving addresses, but you cannot spend the coins.

[yxt]

Just a short note:

I am organizing an asicminer Block Erupter USB groupbuy (Europe):
https://bitcointalk.org/index.php?topic=195037.0

As little support for electrum:

I pay shipping out of my own pocket for all Electrum developers and server operators.