Topic: [ANNOUNCE] Electrum - Lightweight Bitcoin Client - page 62. (Read 274562 times)
signmessage / verifymessage don't seem to work for me, verify always produces False - could someone else test as well?
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!
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.
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)
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.
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?
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.
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.
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://bitcointalksearch.org/topic/electrum-server-discussion-thread-85475
Thanks, ThomasV!
here is a new thread for server-related discussions and announcements:
https://bitcointalksearch.org/topic/electrum-server-discussion-thread-85475
https://bitcointalksearch.org/topic/electrum-server-discussion-thread-85475
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.
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).
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": ["", "mempool:"], "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.
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": ["
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.
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": ["", "mempool:"], "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.
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": ["
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.
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
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)
ecdsa.org is missing transactions again 
I'm curious what's causing this....
I'm curious what's causing this....
I do not know :-(
I should add a detection of this situation in the server
ecdsa.org is missing transactions again
I'm curious what's causing this....
I'm curious what's causing this....
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.
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.
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?
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.
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
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
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.
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:
Quote
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?
Ok I see, so it only needs to know how many addresses were used.
I would definitely prefer an option to restore the full wallet without the network.
If it's a brain-only cold-storage wallet there shouldn't be any problems remembering the amount of addresses. I could easily specify that number during restore process, and if there is more it will generate them when connected to the server. Is this possible to support?
Regarding the source code, I still think it's easier to find an old client than try to mess with a server code just to restore the wallet.
I would definitely prefer an option to restore the full wallet without the network.
If it's a brain-only cold-storage wallet there shouldn't be any problems remembering the amount of addresses. I could easily specify that number during restore process, and if there is more it will generate them when connected to the server. Is this possible to support?
Regarding the source code, I still think it's easier to find an old client than try to mess with a server code just to restore the wallet.
yes it would be possible to support that.
Great! Will be looking forward to it.
So basically client needs to ask how many addresses to pre-generate (5 as default seems reasonable) when creating/restoring a wallet.
Jump to: