No its German.
Another point: I would prefer to import my own keys in offline mode. Thats how I did it with the btcurious build.
-> afk
Ok, I will do some testing and let you know of what I come up with by tomorrow... |
|
|
|
I did it now exactly as described. No import!
I tried with de- and reinstallation, but again the same: the import command is not working. Could it be a Vista problem?
I don't think so but I'm suspecting a codepage issue. Is your OS in English? |
|
|
|
1/ you can import your addresses using my build, I just tried that again with 0.49 and it works, but:
- the wallet must be unencrypted at the time of import
- you won't see any feedback on the command prompt. but when you open the GUI, the imported address will be there.
2/ indeed my build doesn't support text (console) mode yet.
full command-line support is on my to-do list and will be hopefully ready soon.
How can i import an address from the GUI (without the command line)? How can i display the private keys without the command parameters (console)? I think the last btcurious version i used was 0.40 I hope you will soon succeed with the full command-line support. It would be a big gain. I look forward to make a donation to your addr.  Thanks for planning to donate, that's a real motivator to help me prioritize my to-do list  In the meantime, here's how you would import a key with the current build (0.49b): 0. Make sure you're online. This build won't work in offline mode. 1. Open a standard command prompt (Start Menu, Run, type cmd, click OK) 2. Drag the Elec049b.exe icon to the command prompt window. This will insert the full path to the executable. 3. add a space, type "import YourAddress:YourPrivKey" and hit Enter. ( So, if your Elec049b.exe file is on your desktop, your command will look something like this: C:\Documents and Settings\bitcats\Desktop\elec049b.exe import YourAddress:YourPrivKey ) 4. That's it! Open the Electrum GUI by clicking the EXE file normally, and you should be able to see and use your imported address. (5. Repeat as needed, for each address you would like to import) Regarding your second request (how to display your private keys), this will be possible when full command-line support is ready. |
|
|
|
Hello! Due to the newbie restrictions, i can't post this in the "electrum" thread, so i post it here: Electrum is an awesome client but there seem to be some bugs in the "flatfly" windows build: - It only generates new addresses (new wallet) with an online connection. And if the client is closed and then started without a connection, the gui doesnt show the addresses anymore, though they are still in the wallet.dat.
- The command line parameters (eg. import, addresses, ..) dont work!
It doesnt matter, if the wallet is encrypted or not. I use electrum 0.49 - Win Vista With the "old" build from btcurious, it worked! BTW, which version of the btCurious build were you using? Some early versions did have command line support but didn't work well with Windows XP, while the later (Cameyo-based) ones, XP-compatible, no longer supported console mode either, IIRC. But I'm close to finding a solution to that problem. |
|
|
|
For me the client is useless if i can't import and use my own keys. Maybe i can do that using linux and than using the so created electrum.dat with the (flatfly) windows build. I dont know if that works but anyway it is quite a detour.  hi, 1/ you can import your addresses using my build, I just tried that again with 0.49 and it works, but: - the wallet must be unencrypted at the time of import - you won't see any feedback on the command prompt. but when you open the GUI, the imported address will be there. 2/ indeed my build doesn't support text (console) mode yet. full command-line support is on my to-do list and will be hopefully ready soon. |
|
|
|
I don't think so, because when it does go fine all the way to 152, it doesn't take longer to process addresses 115 and 116 than the others. I'll try to reproduce the error while in console mode to see I can get a traceback or something.
if you feel like debugging, you can uncomment the two lines in interface.py that contain "<--" and "-->" it will display the messages sent and received from the server Strange, I never seem to run into the issue when the console is enabled... But I unfortunately don't have much more time to further investigate this right now. And the issue is not a biggie for me, as I just need to kill and re-run Electrum, and the restore/sync then complete fine. |
|
|
|
It displays "synchronizing", but it seems that I do have to kill and restart it before it actually synchronizes.
My wallet file is approximately 500KB.
EDIT: I tried again, this time all went fine with no hiccups, and I found out that I actually have
152 addresses, not 115. So for some reason, it sometimes hangs at or around 115 for me.
maybe your 116th address has a very long history? I don't think so, because when it does go fine all the way to 152, it doesn't take longer to process addresses 115 and 116 than the others. I'll try to reproduce the error while in console mode to see I can get a traceback or something. |
|
|
|
Thanks. I just tested it, and now I can see that when the process stalls
at the last address (115 for me) there is no more data received, and I have to
manually close the window. (First, I tried to wait for 3 minutes but nothing else
was happening)
For your info, I currently have about 250 entries/transactions in my history.
ok, if it stalls then there might be another bug. it could be related to the large size of your wallet; right after you close the window, does the client display "synchronizing", or is it immediately ready? It displays "synchronizing", but it seems that I do have to kill and restart it before it actually synchronizes. My wallet file is approximately 500KB. EDIT: I tried again, this time all went fine with no hiccups, and I found out that I actually have 152 addresses, not 115. So for some reason, it sometimes hangs at or around 115 for me. |
|
|
|
Looks like the current site is vulnerable to a DoS attack through the 'withdraw' method:
In the withdraw form, enter a 34-digit address and any amount of BTC (doesn't matter if you
have them or not), and quickly hit 'Enter' 30 times or more, in rapid succession. The whole site
appears to become unresponsive for at least 10 seconds.
.
Hi Sean, have you had a chance to take a look at this one? I just want to make sure you didn't miss that post due to the high activity in the thread yesterday. Hey, sorry, I started to reply before but must have gotten distracted. I'll keep this in mind but I'm not going to worry about this too much. What this does is not really that expensive of an operation. It makes me wonder if I happened to have restarted the web server at the same time you were trying to do this. Currently, all my javascript is bundled and built the first time a user visits the site upon restart, so this could appear as a long 10second delay to that lucky user. Actually, I did think it could be related to some JIT process or you restarting the server, but I was able to rule this out - I tried at different times of the day, and I can still reproduce the effect right now. Anyway, I can understand that it's not a priority for you at this time, but please don't underestimate this issue, as any script kiddie could potentially DoS (or DDOS) the site through that way - heck, a script isn't even necessarily needed to do it. |
|
|
|
...
way to know in advance how much time is remaining, but the client could display kilobytes downloaded
Yes, this would be good as well - the little touches like that definitely help the end-user experience IMHO ok, I added it to the qt dialog Thanks. I just tested it, and now I can see that when the process stalls at the last address (115 for me) there is no more data received, and I have to manually close the window. (First, I tried to wait for 3 minutes but nothing else was happening) For your info, I currently have about 250 entries/transactions in my history. Screenshot:  |
|
|
|
|
0.49b stand-alone build is now available. (download link in my signature)
SHA-1: 11ade02b8022efcefd2f908381a3e8edfa4faccb
main changes:
* several bugfixes related to imported keys and encryption
* copy seed now copies both hex and mnemonic strings
|
|
|
|
...
way to know in advance how much time is remaining, but the client could display kilobytes downloaded
Yes, this would be good as well - the little touches like that definitely help the end-user experience IMHO |
|
|
|
I released version 0.49b with the above fixes.
changelog:
* fix bug caused by interaction between imported keys and encryption
Great! My Win stand-alone build is now available too. (link in my signature) SHA-1: 11ade02b8022efcefd2f908381a3e8edfa4faccb |
|
|
|
|
A separate issue: the wallet restoration process often appears to stall at the very last address.
In those cases, I then have to close the 'restore' progress dialog manually, then the main window opens normally, but, synchronizing then takes a long time (minutes) - is it possible to show some kind of progress (in %, or blocks) in the status bar? Just so the user knows if the program is actually doing something or not.
|
|
|
|
I commited two fixes.
let me know if there are still problems.
Thanks, things look good to me so far. |
|
|
|
Looks like the current site is vulnerable to a DoS attack through the 'withdraw' method:
In the withdraw form, enter a 34-digit address and any amount of BTC (doesn't matter if you
have them or not), and quickly hit 'Enter' 30 times or more, in rapid succession. The whole site
appears to become unresponsive for at least 10 seconds.
.
Hi Sean, have you had a chance to take a look at this one? I just want to make sure you didn't miss that post due to the high activity in the thread yesterday. |
|
|
|
ok, use the command line, and generate the same transaction with mktx.
there will be a traceback. post it here.
There you go: python electrum mktx -f 0.001 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 0.002 Password: Traceback (most recent call last): File "electrum", line 416, in <module> fee = options.tx_fee, change_addr = change_addr, from_addr = from_addr ) File "%AppData%\Electrum-P\R049\C_\ElectrumPY\electrum\wallet.py", line 782, in mktx s_inputs = self.sign_inputs( inputs, outputs, password ) File "%AppData%\Electrum-P\R049\C_\ElectrumPY\electrum\wallet.py", line 679, in sign_inputs private_key = ecdsa.SigningKey.from_string( self.get_private_key(addr, password), curve = SECP256k1 ) File "%AppData%\Electrum-P\R049\C_\ElectrumPY\electrum\wallet.py", line 384, in get_private_key b = self.pw_decode( self.imported_keys[address], password ) File "%AppData%\Electrum-P\R049\C_\ElectrumPY\electrum\wallet.py", line 698, in pw_decode d = DecodeAES(secret, s) File "%AppData%\Electrum-P\R049\C_\ElectrumPY\electrum\wallet.py", line 153, in <lambda> DecodeAES = lambda secret, e: aes.decryptData(secret, base64.b64decode(e)) File "%AppData%\Electrum-P\R049\C_\Python27\lib\base64.py", line 76, in b64decode raise TypeError(msg) TypeError: Incorrect padding None FFLY_VM> |
|
|
|
are there imported keys in your wallet?
(I am asking this because you reported that the bug does not occur right after you regenerate the wallet)
Yes, I do have one imported key. In my tests, problems usually don't begin right after the import, more like a few hours (or transactions, not sure) afterwards. |
|
|
|
|
Nice figures, thanks for that!
But now I'm wondering how many Linux users use apt-get and other methods rather
than regular download...
I am sure the % of Bitcoin users running Linux must be way higher than 10%.
|
|
|
|
Hi Thomas, thanks for that new release. Indeed, I am able to get a readable error message now. (The test address in the below screenshot is the ECDSA node, copy-pasted)  |
|
|
|
|
Show Posts
