interlagos
|
|
June 01, 2012, 07:21:05 PM |
|
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?
|
|
|
|
|
Tuxavant
|
|
June 01, 2012, 08:56:25 PM |
|
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
|
|
June 01, 2012, 10:20:09 PM |
|
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
|
|
June 01, 2012, 10:32:43 PM |
|
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
Donator
Hero Member
Offline
Activity: 668
Merit: 500
|
|
June 02, 2012, 03:19:50 AM |
|
ecdsa.org is missing transactions again I'm curious what's causing this....
|
|
|
|
ThomasV (OP)
Moderator
Legendary
Offline
Activity: 1896
Merit: 1353
|
|
June 02, 2012, 06:40:41 AM |
|
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
|
Electrum: the convenience of a web wallet, without the risks
|
|
|
interlagos
|
|
June 02, 2012, 07:05:54 AM |
|
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
Newbie
Offline
Activity: 44
Merit: 0
|
|
June 03, 2012, 01:05:59 PM |
|
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
Legendary
Offline
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
|
|
June 03, 2012, 01:15:11 PM |
|
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
Newbie
Offline
Activity: 44
Merit: 0
|
|
June 03, 2012, 05:11:11 PM |
|
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
Legendary
Offline
Activity: 1092
Merit: 1016
760930
|
|
June 04, 2012, 08:44:33 AM Last edit: June 04, 2012, 09:35:45 AM by 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.
|
|
|
|
|
anfedorov
Newbie
Offline
Activity: 44
Merit: 0
|
|
June 04, 2012, 11:01:51 PM |
|
EDIT1: are you using the Windows build? The issue could be specific to Windows builds. I will investigate further.
No, this was on Ubuntu. Thanks, ThomasV!
|
|
|
|
anfedorov
Newbie
Offline
Activity: 44
Merit: 0
|
|
June 05, 2012, 01:10:14 AM |
|
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
Legendary
Offline
Activity: 1092
Merit: 1016
760930
|
|
June 05, 2012, 08:04:16 AM |
|
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 (OP)
Moderator
Legendary
Offline
Activity: 1896
Merit: 1353
|
|
June 05, 2012, 12:30:51 PM Last edit: June 05, 2012, 02:38:15 PM by 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)
|
Electrum: the convenience of a web wallet, without the risks
|
|
|
anfedorov
Newbie
Offline
Activity: 44
Merit: 0
|
|
June 05, 2012, 06:06:20 PM |
|
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
Legendary
Offline
Activity: 1092
Merit: 1016
760930
|
|
June 06, 2012, 11:16:18 AM |
|
signmessage / verifymessage don't seem to work for me, verify always produces False - could someone else test as well?
|
|
|
|
ThomasV (OP)
Moderator
Legendary
Offline
Activity: 1896
Merit: 1353
|
|
June 06, 2012, 11:25:50 AM |
|
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.
|
Electrum: the convenience of a web wallet, without the risks
|
|
|
|