So i think its the RAM issue, system says running 4GB, 3GB usable. Just checked machine and says online, the minute i click on something i get the "not responding" msg and have to close it down.
I have an older Armory (0.82.2) running on my laptop which does have 4GB RAM and i used last year. So taking into account i'm pretty computer spaz, to get back my 5 BTC do i copy the Armory.wallet file into Armory on my laptop?
thanks again.
By the way, you will not be able to use versions of Armory older than 0.86 with the latest Bitcoin-Qt. You should get the latest: 0.87.2. The latest bitcoin-qt updates broke older versions of Armory. |
|
|
|
after digging around a bit more I believe the problem is more than simply encoding. The consumer of my signature (bitcoin-otc's verifier) is expecting the signature output from Bitcoin-Qt which is base64-encoded. I thought that the Armory signature was equivalent but I now think there's a missing byte. Bitcoin-Qt's signature is 65 bytes while Armory signatures are 64 bytes. It looks like Bitcoin-Qt includes a header byte that Armory does not. Can you make Armory's signatures compatible with Bitcoin-Qt? key.cpp:
// create a compact signature (65 bytes), which allows reconstructing the used public key
// The format is one header byte, followed by two times 32 bytes for the serialized r and s values.
// The header byte: 0x1B = first key with even y, 0x1C = first key with odd y,
// 0x1D = second key with even y, 0x1E = second key with odd y
bool CKey::SignCompact(uint256 hash, std::vector<unsigned char>& vchSig)
Oh, that's some special format that allows them to do key reconstruction from the signature. Except, I don't even know how to do it, so I couldn't implement it if I wanted. At the moment, it's not even used for anything (that I'm aware of). The core devs gave me some documents about it, but I never grokked them. Armory signs the data the same way as the rest of the network does, or else it wouldn't get accepted into the blockchain. The signature scheme you're looking at there is special. Perhaps there's a different code interface that you can access that takes the default, DER-encoded signatures that go into the actual transaction serialization. Or you could implement the key reconstruction for me  |
|
|
|
So i think its the RAM issue, system says running 4GB, 3GB usable. Just checked machine and says online, the minute i click on something i get the "not responding" msg and have to close it down.
I have an older Armory (0.82.2) running on my laptop which does have 4GB RAM and i used last year. So taking into account i'm pretty computer spaz, to get back my 5 BTC do i copy the Armory.wallet file into Armory on my laptop?
thanks again.
Yeah, you can copy the wallet file to another version of Armory. Or you can load Armory in offline mode (from the Start menu) and then you can "Backup Individual Keys" to get the private keys out of your wallet. A lot of other apps allow key importing. |
|
|
|
So do I understand correctly that for people using proxies (mainly for Tor), you *may* have to do any of the following: - (1) Create a bitcoin.conf file with listen=1 (C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf or /home/user/.bitcoin/bitcoin.conf)
- (2) Start Armory with --skip-online-check
- (3) In some cases, change the port that Armory connects to (usually 8333, might be 9050 with Tor)
Does this cover it? What else should I add to my list? |
|
|
|
No, I restarted computer and the same windows stopped program
Thank you for being so patient. If you could just do one more thing for me. Email me a full copy of the log file. It is in C:\Users\username\AppData\Roaming\Armory\armorylog.txt. The unicode problem is preventing you from exporting it normally. I really need to see the whole file. etotheipi@gmail.com |
|
|
|
I can open it in offline mode or only when i not connected to internet
Can you please try rebooting? The log file you sent looks like Armory might already be open even though you cannot see it. |
|
|
|
|
There's two potential problems:
(1) Armory is not yet unicode-friendly. Unfortunately, when I started developing Armory, I did not realize that there was stuff I needed to do to support unicode and multiple languages. Since your system is in Russian, it's probably choking on some Russian unicode characters, or strange date formats. I'm working on an epic new wallet format, which I have promised myself will be unicode-compatible.
(2) It looks like there's a zombie Armory process running in the background. Perhaps one of the older versions you tried using crashed, but never fully exited, and now is blocking Armory from opening. Can you look in your process list and try to kill it? Or maybe reboot? I don't know if Armory will play nice with the Russian stuff, but you might at least get it to open.
|
|
|
|
Windows 7 Pro, 16 gb ram, 3600 amd cpu
That system shouldn't have any problems. Are you sure you tried 0.87.2? The only place you can even get version 0.76 (github) does not have the latest version. Also, I recommend doing a full uninstall and maybe even remove the C:\Program Files (x86)\Armory directory, before reinstalling the latest. Also, please try it in offline mode, too. There's a launcher in the start menu for it. It is extremely useful to know whether it works in offline mode, and you can easily get me a log file. Thanks for being patient! |
|
|
|
I downloaded all versions of armory and only versions 0.75 and 0.76 can launch all other versions windows stopped this program
What are your system specs? Right now, online Armory is pretty intense, and a system with less than 4 GB is probably not going to do very well. This will be fixed in the next couple weeks, I believe. Can try the latest version again. Try running it. Then try running it in offline mode (there's a launcher with "(Offline)" installed in the Start->Applications->Armory menu). If it opens in offline mode, please use File->Export Log File. And email or PM me the log file. If you can't even open it in offline mode... then something is really out of whack. You'd have to grab the logfile directly from C:\Users\username\AppData\Roaming\Armory\armorylog.txt. Sorry you're having such a bad experience! Hopefully I can figure out what went wrong! -Alan |
|
|
|
Are you using versions of Armory older than 0.80? I wouldn't expect those to even work anymore! And versions older than 0.86 probably won't work with Bitcoin-Qt 0.8.0. Please download the latest version of Armory from the website. 0.87.2 is the latest, and 0.88 will be released soon (hopefully!). |
|
|
|
I haven't found a john the ripper implementation for ECDSA, or it doesn't exist. From the code you pasted, it seems that the real issue here is the 10000 rounds of SHA256, not the ECDSA. It may be worth trying to put only the "stretch_key" method on a gpu, and then do the ECDSA on the CPU. Probably much less work to implement, but still a significant speed-up compared to naively running this python script. A friend of mine said that he tried but he can't run ecdsa at a good speed... Not sure of why this doesent agree with other posts here... I think I read that openssl has a purposely crippled implementation because otherwise timing information is leaked which can be used to recover the private key. I don't know the details, but there was a thread about it on here at some point. Maybe that's the problem - try a different ECDSA library designed for speed rather than security. ECDSA is slow. No matter how you look at it. Implementations slow it down further in order to improve robustness to things like timing attacks, but you're just not going to get a fast implementation on a CPU. I think 1,000/sec/core is about what you can expect. But the other poster is right -- this is not really an ECDSA problem -- it's a hashing problem. And there's plenty of hashing algos already implemented on GPUs. It is probably reasonable to run hashing on the GPU, and then send a steady stream of results to the CPU for checking the answer. Even if your GPU has lots of cores, I'm not sure it will out-pace the CPU-ECDSA compute speed. This is probably a reasonable approach. |
|
|
|
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1104 - Setting up networking...
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1149 - Internet connection is Available: True
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1150 - Bitcoin-Qt/bitcoind is Available: 0 That 0 is returned when it can't communicate with Bitcoin-Qt/bitcoind (it normally returns the port number on which it was found, though by default it only searches one port). Is it possible that you are using different command line arguments for it? Bitcoin.conf file? I'm really at a loss for this one... No command line qrguments for bitcoinqt. bitcoin.conf is rpcuser=generated_by_armory
rpcpassword=hidden Can you PM me the top of the log file so I can see what directories and ports it's choosing. This isn't adding up... |
|
|
|
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1104 - Setting up networking...
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1149 - Internet connection is Available: True
2013-04-02 01:07 (INFO) -- ArmoryQt.py:1150 - Bitcoin-Qt/bitcoind is Available: 0 That 0 is returned when it can't communicate with Bitcoin-Qt/bitcoind (it normally returns the port number on which it was found, though by default it only searches one port). Is it possible that you are using different command line arguments for it? Bitcoin.conf file? I'm really at a loss for this one... |
|
|
|
The automatic mode calls bitcoind successfully, but stopped at inititalizing bitcoin engine. Nothing interesting in log.
Strange question: is your clock UTC or local? I ran into an infinite-initializing problem when my clock was set wrong. Now that I bring it up myself, I guess I should actually make it clock-independent. I've conceded that some OS will just have to do manual mode (OSX, probably XP). But I'm not sure why that broke for you. Can you check the log after trying it in manual mode? |
|
|
|
It's even worse
Error: "The specified module could not be found. LoadLibrary(pythondll) failed"
Error: "C:\Program Files (x86)\Armory\Armory Bitcoin Client\PYTHON27.DLL
That's happened before when there's been some kind of messup in the install directory. Can you completely uninstall it and remove the C:\Program Files (x86)\Armory directory. Then reinstall. It should go away. I never quite figured out what conditions cause that... |
|
|
|
Also, has anyone figured out a method to take some seed that can just generate public addresses on an exposed merchant server that would have a private seed on a secure machine that could generate the corresponding private keys? Does anyone have any code in any language to do this?
That's exactly what Armory does. See the Offline wallet tutorial. All private keys are on computer that never touches the internet. Watching-only wallet on online computer only contains public keys. Both wallets are really the same wallet, generate the exact same semi-infinite sequence of addresses, but anyone getting ahold of the watching-only wallet cannot take the funds. |
|
|
|
So i've been mining for quite some time but still quite rubbish with computers.
This morning i downloaded Armory to machine and sent 5 BTC, i got the scanning block chain for about 1hr and then a not responding msg, finally synced briefly but no sign of BTC in wallet and then get a Armory not responding msg again.
When i look in Blockchain.info i can see the 5 BTC transfer with 77 confirmations, but no sign of them in Armory. In other posts i see people mentioning doing a rescan, how do i do that with Windows 7?
Thanks in advance for help and please bear with me, i'm sure i'll have a question regarding possible fix's.
P.S. Used Armory last year on my laptop quite a bit and really liked it, bit disappointed its not working so great now and more importantly to have possibly lost 5 BTC.
Your coins are not lost. Armory still has never lost coins unless users have explicitly deleted something. The problem is usually that it's not fully sync'd. The updates that I'm pushing out right now should simplify this considerably (Armory will manage bitcoin-qt/bitcoind itself, and only connect when it's properly synchronized). If you restart Armory it will rescan. But it can only read it if Bitcoin-Qt/bitcoind is up to date. Wait for the green checkmark. And make sure that Armory is pointing to the same -datadir as you're using for Bitcoin-Qt/bitcoind (using --satoshi-datadir in Armory). If it took an hour to scan, I would guess your online computer doesn't have 4 GB of RAM. Or you're using all your RAM for other things. That too will be fixed, it's just not, yet. Until then, you have to have a spare 2 GB for Armory. Worst case, you can always export the private keys from Armory and import them into another app, if you really can't use Armory. |
|
|
|
Okay, I fixed a big bug that had to do with non-standard --satoshi-datadir settings. Hopefully that is resolved in both Linux and Windows. And a ton of other fixes, so I at least have more information if there are failures. I still have not tested it in WinXP, so it probably won't work there, or any other XP-like OS. But otherwise, it's starting to really come together. The top post has been updated with the latest information. Please try it out, in both Linux and Windows! |
|
|
|
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for. I think the default configuration for most users is that they operate on a trusted network, whether that is a home LAN, or a business network. If I operate both machines, then neither one is an untrusted peer to the other. Perhaps you can loosen the rules a bit to allow Armory to consider any host on the same non-public address block (ipv4) or on a link-local address (ipv6) to be considered a trusted peer, and not just 127.0.0.1 without compromising security appreciably. Technically, it's not restricted right now. I've had a couple users tell me they setup their --satoshi-datadir on the an nfs or sshfs directory, and pointed Armory to the remote host. There's no command line option for it, but most of these people are running Linux, and it's a one-line change in the python code. I *could* add a command line option, but I will wait until I have the semi-independent blockchain management. If I added the option right now, it would be worthless to most users... |
|
|
|
|
The problem here is this:
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for. Right now, there's no choice: Armory relies on localhost Bitcoin-Qt/bitcoind, which if that is compromised, Armory is hosed anyway. The first time it is allowed to connect to non-localhost (after it gets its own blockchain mgmt), I know people will start connecting it to untrusted nodes, not realizing that it's really bad news. Armory has what it has because hiding behind a trusted bitcoind gives it all the security properties of bitcoind, without spending any time developing it (and probably doing a terrible job and forking the blockchain). Instead, I've been able to focus on features, instead of re-doing what the core devs do.
However, at some point, I will be splitting Armory into both directions: lite-node and super-node. The Armory super-node would be like the Electrum servers, allowing arbitrary address lookup. It would be hiding behind a single bitcoind instance, and all the lite-nodes can connect directly to it. I'm sure people will run malicious Armory super-nodes, but at least in this case, Armory lite-node is depending a lot less on that connection: it basically turns their computer into an offline signing system (even though it's technically online) -- the super-node accumulated all the transaction data, and then gives it to the lite-node to sign. Then the lite node can broadcast. I've actually made sure that that process is secure, even if the online computer (or supernode) is malicious.
There's quite a bit of work to do on that front, though...
|
|
|
|
|
Show Posts
