[ANNOUNCE] Electrum - Lightweight Bitcoin Client

[interlagos]

use the -o (offline) option when working with wallets on a non-networked computer.

You can create more than 5 addresses by editing the code, but you have to remember to do that same count when/if you restore in the future. I believe the actual line/file you need to change is documented earlier in this thread.

Line 257 in wallet.py:

self.gap_limit = 5           # configuration

Or, new receive addresses get automatically created by the client as you use the existing ones.

Thanks for you comments guys, first -o option doesn't seem to affect the generation of addresses/private keys, they are not created in offline mode. Second I haven't tried it but I thought that gap_limit was the amount of addresses that could be imported without breaking the sequence, not the overall amount of addresses. Is that correct?

[1714212268]

1714212268

[1714212268]

1714212268

[Lumpy]

From here:

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

To create an offline wallet, use:

electrum -o create

or if you want a specific file:

electrum -o -w walletfile create

[Tuxavant]

Just FYI... When I say "offline" I'm literally talking like "this computer does not have a network interface"... '-o' in my experience working with an "offline" computer, generally needs the option or python will try to connect to a device that doesn't exist and explode in your face.

[Lumpy]

Are you making a distinction between zero network interfaces and zero connected network interfaces? The latter seems to work for me. Guess not the former?

[Tuxavant]

hum... well, for me, it's a netbook with a wifi device, but it is unconfigured softwarically (lol)... This machine is running linux too. I wonder if that makes any difference.

In any case, when I'm using that netbook, I have no problems when I use -o, and typically get locked up or crash when I don't.

[zebedee]

ecdsa.org is missing transactions again   

I'm curious what's causing this....

[ThomasV]

ecdsa.org is missing transactions again   

I'm curious what's causing this....

I do not know :-(
I should add a detection of this situation in the server

[interlagos]

From here:

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

To create an offline wallet, use:

electrum -o create

or if you want a specific file:

electrum -o -w walletfile create

Yes it creates the wallet file that way, but if you then type:
electrum addresses -ak
it won't print any, that's the problem for me.

I already asked Thomas about the fix and he said it should be possible, so no worries.

PS: I'm using Ubuntu 10.10 Live CD with Wi-Fi device turned off (physically)

[anfedorov]

I just started playing around with the client, and it's pretty neat!

However, after a bit of testing, there seems to be a bug in the JSON-RPC over HTTP service at ecdsa.org:8081 (and no bug over TCP on 50001). Over TCP, transactions to an account the client is subscribed to yield a nearly instantaneous message from the server of the form:

<-- {"params": ["<account>", "mempool:<len(h)>"], "method": "blockchain.address.subscribe"}

Whereas the HTTP version doesn't seem to report anything to the polling requests.

Could someone verify that this isn't me making some trivial mistake? I used "sudo ngrep -q -Wbyline '' dst host 78.47.154.42 or src host 78.47.154.42" to watch the traffic.

[Xenland]

I just started playing around with the client, and it's pretty neat!

However, after a bit of testing, there seems to be a bug in the JSON-RPC over HTTP service at ecdsa.org:8081 (and no bug over TCP on 50001). Over TCP, transactions to an account the client is subscribed to yield a nearly instantaneous message from the server of the form:

<-- {"params": ["<account>", "mempool:<len(h)>"], "method": "blockchain.address.subscribe"}

Whereas the HTTP version doesn't seem to report anything to the polling requests.

Could someone verify that this isn't me making some trivial mistake? I used "sudo ngrep -q -Wbyline '' dst host 78.47.154.42 or src host 78.47.154.42" to watch the traffic.

If you go up(maybe back a page or two) I read some people were getting balance mistakes from the ecdsa.org server but valid on every other server. it sounds like a mix up on the ecdsa servers only. This is a perfect example why lite bitcoin clients should always cross verify more then 2(or even 6) servers that which are owned/operated by different entities to gain confidence during transaction send/receiving, and information/balance queries.

[anfedorov]

However, after a bit of testing, there seems to be a bug [...]

If you go up(maybe back a page or two) I read some people were getting balance mistakes from the ecdsa.org server but valid on every other server. it sounds like a mix up on the ecdsa servers only. [...]

I just tried it on electrum.novit.ro and btcback.com with the same results: when the client is connected over TCP, an incoming transaction generates the appropriate server->client message in 5-10 seconds, whereas if the client is connected over HTTP, nothing happens (I waited ~2 minutes before restarting the client, at which point the transaction shows up).

[flatfly]

However, after a bit of testing, there seems to be a bug [...]

If you go up(maybe back a page or two) I read some people were getting balance mistakes from the ecdsa.org server but valid on every other server. it sounds like a mix up on the ecdsa servers only. [...]

I just tried it on electrum.novit.ro and btcback.com with the same results: when the client is connected over TCP, an incoming transaction generates the appropriate server->client message in 5-10 seconds, whereas if the client is connected over HTTP, nothing happens (I waited ~2 minutes before restarting the client, at which point the transaction shows up).

Confirmed, HTTP fails for me too. 

EDIT1: are you using the Windows build?  The issue could be specific to Windows builds. I will investigate further.

EDIT2: I have fixed this in Windows build 0.53-2 (just released) - There were some HTTP-related
libs missing following the upgrade to Python 2.7.3.1.

[ThomasV]

here is a new thread for server-related discussions and announcements:
https://bitcointalk.org/index.php?topic=85475.0

[anfedorov]

EDIT1: are you using the Windows build?  The issue could be specific to Windows builds. I will investigate further.

No, this was on Ubuntu.

here is a new thread for server-related discussions and announcements: https://bitcointalk.org/index.php?topic=85475.0

Thanks, ThomasV!

[anfedorov]

EDIT2: I have fixed this in Windows build 0.53-2 (just released) - There were some HTTP-related
libs missing following the upgrade to Python 2.7.3.1.

Was this a problem on the client? From what I see in the traffic, the client is polling the server just fine - it's just not getting back the transaction notification.

[flatfly]

EDIT2: I have fixed this in Windows build 0.53-2 (just released) - There were some HTTP-related
libs missing following the upgrade to Python 2.7.3.1.

Was this a problem on the client? From what I see in the traffic, the client is polling the server just fine - it's just not getting back the transaction notification.

On Windows, there was a problem on the client with HTTP connections, which is now fixed. But it seems that what you are reporting is perhaps a separate issue. What is the command you are using in your tests? Do you have the same issue with the "electrum balance" command?

[ThomasV]

EDIT2: I have fixed this in Windows build 0.53-2 (just released) - There were some HTTP-related
libs missing following the upgrade to Python 2.7.3.1.

Was this a problem on the client? From what I see in the traffic, the client is polling the server just fine - it's just not getting back the transaction notification.

I confirm that there is a problem with notifications and http. I am investigating it

edit: this was a server bug. I fixed it. it should work now (at least on ecdsa.org)

[anfedorov]

edit: this was a server bug. I fixed it. it should work now (at least on ecdsa.org)

Just re-tested it, and it looks like it's working on ecdsa.org. Thanks for the quick response!

[flatfly]

signmessage / verifymessage don't seem to work for me, verify always produces False - could someone else test as well?

[ThomasV]

signmessage / verifymessage don't seem to work for me, verify always produces False - could someone else test as well?

I am aware of the issue; there are two problems:
 - a module was mising in setup.py this is fixed in git  (see recent commits)
 - verifymessage fails with compressed keys (the new format used by the satoshi client). the result is that it will return False on a string signed by the satoshi client using a recent wallet. this was reported by nanotube. it is not fixed yet.