Topic: Armory - Discussion Thread - page 137. (Read 521749 times)

I think switching to Hard Drive over Ram storage for the blockchain is a very good idea. Armory is by far my favorite Bitcoin wallet, but the system strain is getting extremely high running it 24/7.

Excited for the future update, thanks for your hard work! 

after which it booted fine the first time. Then after a reboot the same happens however after logging in (which goes fine) after which the screen distorts for a while, which goes away after a few seconds. Subsequently, I see a background but no menu bars whatsoever. The OS is responsive though with mouse actions working fine and control+alt_t giving me a terminal which also works fine.

I think it is to do with my (old) on-board Intel graphics card. I have followed the instructions here http://ubuntu-tutorials.com/2010/05/06/ubuntu-10-04-lucid-blank-screen-at-startup-workaround/ (note that here it says blank screen but elsewhere people report problems similar to mine and people link to this solution) but to no avail.

Just posting this here in case anyone knows what to do because I am stuck right now. Otherwise I'll probably figure it out sometime (or get a bigger case for the other HW or order a Raspberry pi)


Edit:

Not really a solution but if I start a terminal and type killall gnome-panel suddenly all my menus appear ....
All the other weird behaviour (such as the 2 error messages and the gurbled screen on startup) are still there so not so much a solution. So I would still appreciate feedback. How do I fix this? And in how far is this a stable system/install?

Edit 2:

Okay, I went on anyway and installed the offline Armory package which went really smooth. I created a paper backup (No printer so I used e and paper thanks for the lower case letter only format ) and restored it.

1) This goes very smoothly. I made a typo and it corrected it correctly (I guess there is a error correcting code in there)
2) When restoring a paper wallet and encrypting it is not possible to encrypt it more difficult than the default setting and that is only 128 KB on my system while the menu recommends 2 MB.
3) I Send 0.10 BTC to my cold wallet. After dinner I'll try to get it back

Edit 3:

And at a cost of 0.0005 BTC (fee) I managed to complete the transaction

And possibly related to the problems I describe earlier in this post: In upper-right part of the screen a do not enter traffic sign appeared notifying me I have broken dependencies.


It keeps adding [/code] to the end of my post for no apparent reason. I really have put the sight number of tags. This is very annoying.[/code]

Indeed.  This is something I noticed which happens when there is a re-org/orphaned block.  It inspired me to re-run some unit-tests that hadn't been run in a while, and led to semi-release of 0.87.2 (only available from the googlecode download page).  I never made an official release, because I had released 0.87 a couple days earlier and didn't want to spam users with it.

Until you upgrade, restarting is the only thing you can do. 

EDIT: Actually, I don't think it was re-orgs, I think actually when two blocks are received at the same time...  well doesn't matter... both were fixed in 0.87.2.


I don't have a good way to describe the entropy generation:  it is handled by the Crypto++ library's AutoSeededRandomPool, which is a FIPS-140-2 validated cryptographic library.  It is considered "suitable for cryptographic purposes."



Armory does test system speed and sets the encryption parameters.  This is not the same as the deterministic key generation ... that always takes the same amount of time.  What is adjusted is how long it takes to convert your passphrase into the encryption key used to encrypt your wallet.  Basically, how long you have to wait between entering your passphrase and pressing , and when the keys actually get unlocked.   

When you create the new wallet, there will be "Advanced Options" where you can adjust the time and RAM usage of the key-stretching.  The longer the amount of time you specify, the more computation it does, and the more RAM it will use.  Note that RAM usage above 64 kB is acceptable for disarming GPU-acceleration.   If you set the time really long, you will get up to 32 MB, which is extraordinary overkill.  The point is, it is configurable.  You can make it up to 20 seconds if you want, but it will be pretty annoying to sign transactions.

Quote from: wachtwoord on February 28, 2013, 07:02:04 PM

3) If I understand correctly, a paper wallet is a direct representation of the root key that can be used to generate all public/private key pairs that will ever be generated in a wallet AND that this is also true for a encrypted wallet. So:

3a) Won't that circumvent the security of the wallet encryption?  If someone physically gains access to my paper wallet he will still be able to take my funds even though I encrypted the wallet?
3b) Is there a way to make an encrypted paper wallet? Restoring such a paper wallet would require typing in the paper wallet and subsequently decrypting it using the encryption key to decrypt it and once again have access to all public/private key-pairs.

You are correct, the paper backup is not encrypted.  The goal is to protect against digital/virtual threats, not physical threats.   If you are concerned about physical security, you should put it in a safe-deposit box at a bank.  There is no encrypted paper backup option, though there is a "fragmented" backup option coming with the new wallets!  If you really want to encrypt your backup, then make a digital backup of your wallet to a USB key or a CD (which will be encrypted if your wallet is encrypted).  Just be sure to make a couple copies in case one fails.  Though, it's highly recommended you make at least one plaintext backup and keep it physically secured.  Your family will thank you for that (post-mortem) if something terrible were to happen to you.

When I'm done with the new wallets, I'll be reworking the backup system into a single, complete dialog that will walk you through the process and provide all the appropriate warnings.

Quote from: wachtwoord on February 28, 2013, 07:02:04 PM

4) You linked to a site explaining how to disable autorun of inserted USB devices on Windows. How can this be done in Ubuntu 10.0.4?

Luckily, all Linux distros are expected to default to no-autorun at all.  However, the default is to automount and *ask* you if you'd like to run something on the inserted drive.  This isn't the same thing as "no autorun vulnerabilities", but it does cut down on them by an order of magnitude.   You can google for a few ways to configure this behavior.  I left it out because it's probably confusing to some users and not so necessary when the autorun is already disabled.  Here's some links. 

http://ubuntugeek.com/forum/index.php?topic=4639.0
http://ubuntuforums.org/showthread.php?t=974087

While Ubuntu is installing on the system that is going to be my offline system I re-read (I read it the last time a few weeks ago) all the documentation on the Armory website. Everything regarding the issuing of offline transactions is explained very well, I don't think I'll have problems with that. I do have four questions remaining:

1) The wallet generated by Armory is deterministic; if you have access to the root key you can generate all public/private key pairs that will ever be generated for that wallet. In essence you have access to all the funds attributable to the addresses in that wallet. So my question is: can you explain how the entropy generation is handled for generating the initial root when I generate a new wallet and how this is secure?

This came up due to the discussions I read about Vanity address generators that were supposedly insecure. In essence, if you searched for the same search-string on similar hardware the same public/private key came out.

2) I recall from generating a wallet on my main system that, when creating an encrypted wallet, the level of encryption is determined by the speed of the system generating the wallet. Since I am using a crappy computer to generate the wallet will it be secure? Also, can I increase the encryption level manually? (I don't care if it will take the system hours to generate a wallet since it will be a one-time event).

3) If I understand correctly, a paper wallet is a direct representation of the root key that can be used to generate all public/private key pairs that will ever be generated in a wallet AND that this is also true for a encrypted wallet. So:

3a) Won't that circumvent the security of the wallet encryption?  If someone physically gains access to my paper wallet he will still be able to take my funds even though I encrypted the wallet?
3b) Is there a way to make an encrypted paper wallet? Restoring such a paper wallet would require typing in the paper wallet and subsequently decrypting it using the encryption key to decrypt it and once again have access to all public/private key-pairs.

4) You linked to a site explaining how to disable autorun of inserted USB devices on Windows. How can this be done in Ubuntu 10.0.4?

Thanks in advance

Well a Raspberry Pi is actually superior to this system


I managed to actually read and found that for offline systems etotheipi made a offline bundle for Ubuntu 10.0.4 specially so I guess I'll use that. Thanks for your opinion though. I am aware for Linux distro preference taste is a big factor, but figured for this specific use case there might be reasons for one over the other.

..should do fine, with that hardware.
Hey, people are using a Raspberry Pi for Armory offline wallets! :-)

I, personally, switched from Ubuntu to Debian, some years ago. And I think everybody will only give you their personal opinion, so here's mine ;-)
Also, it seems like a lot of people here use Debian too.

Ente

Mine does that every now and then as well. Only solution I've found is to shut down and restart. Would be great to have a "resync" button... but if the plan is to go with a standalone Armory, that might be unnecessary.

A minute ago I noticed a tx in Armory still is at 2 confirmations only.
'bitcoind getinfo' says 223646 blocks,
Armory says 'connected 223630 blocks'.
Armory 0.87, bitcoind 80000.

Anything I should do, like pulling a log or something?
Else I'll just restart Armory or shutdown my pc to get some sleep..

Ente

Strange.  Can you confirm that they aren't all in your wallet, now?  Just to be sure that it didn't silently succeed!  

If 1-3500 succeeded and it failed at 3501, can you try importing just 3502+ and see if it works?  There's certainly no limit on the number of keys that can be imported, I'm just wondering if there's something funky about the first key that failed.  Also, I suppose something like invisble binary characters in the text stream could be the problem.  Can you try copying and pasting just the 64-hex-chars without any trailing or leading whitespace?  

Also, I doubt this is your problem, but if that key is higher than 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, then it's not actually a valid key and Crypto++ chokes on it.  I have run into this before, when I was making fake keys just to test some armory code and "FF"*32 was causing garbage answers (and frequently segfaults!).  Now that I mention it, I don't know why I don't put a check for this in the GUI... 

EDIT: Just to be clear:  of the 2²⁵⁶ 32-byte integers, the top ~2¹²⁸ are not valid ECDSA keys, approximately 0.000000000000000000000000000000000000001% of them -- no one bothers talking about it because the chance of picking an invalid one by accident is nil.  But if you are creating simple keys manually for whatever reason, it's possible to run into this -- I know at least one other user who has done the same thing!

By the way, I saw your extract-keys pull request... I will look at it in a bit... I'm a bit swamped with things.  But I've been meaning to update the app to be a little more flexible with those things...

too lazy to delete my personal info from it so pmed you the whole thing. 

Weird!  I've never seen that before!  Can you send me a log file?  I can't even think of how that is possible without actually being on testnet.  But Armory is very good about not mixing networks -- it's always checking prefix bytes and magic bytes to make sure you're not connected to the wrong thing.

Glad it's [mostly] working for you!  Let me know if you run into anything else.

Turned out port 8333 was used? Anyway I started bitcoind on a different port (Still cannot figure out what is using port 8333). And used "python /usr/share/armory/ArmoryQt.py --satoshi-port=8330"

Now all peachy thanks. Just a weird thing. Armory is on the main network. shows balances and all good. But on unity it shows the testnet icon (green) with testnet label.

This is the right place.  And stop apologizing!  Bug reports are good.  Thank you.

The install location is not the important part, it's the home directory.  It sounds like you're in Linux, so it's looking for /home//.bitcoin.  This value can be overridden using the "-datadir" arg when running bitcoind/-qt.  If it is different, run Armory with the " --satoshi-datadir=/path/to/new/home" option.

The other thing it needs is the correct port:  Armory expects to find bitcoind/-qt responding on port 8333.  If you changed that, you need to run Armory with the " --satoshi-port=X" option.

If that doesn't help, can you please email or PM me the end of your log file?  You should be able to export it from Armory in offline mode.

Reporting a bug. Don't kill me with "not the place". I am sorry for that!

Bitcoin-QT running (v0.8.0)
Armory (v0.87)

Armory always running in offline mode claiming that Bitcoin-QT isnt running or isnt synchronized (it is btw).

Running ubuntu 12.10 64-bit.

Expectations for the problem:
- The binaries from the PPA are buggy and hangs at block-chain download. So I am using the downloaded binaries from bitcoin.org

Maybe Armory checks a "default" location for bitcoind, bitcoin-qt and doesnt find it so it assumes it is not installed? Sorry again didnt get a chance to check the source code .


Alot of sorries are there. And again I am sorry. Just wanted to report this.

I had issues where windows would hang (but not showing high RAM use, possibly I/O congestion) when running bitcoin/armory.
So, I'm upgrading bitcoin to the 0.8 on windows (64bit).
I have the 0.87 armory atm, should I upgrade? if so, which one would perform the smoothest with least probability of hanging the system? (64/32 etc.)
Thanks, I like the coin control.

I actually posted about this yesterday.  Since then, I reverted back to 6.2 (to stay consistent with the other computer).  I deleted blkindex and am currently rescanning the blockchain with bitcoind.  I figured this might do the trick.  I'll post the results.

That means that Armory is not finding the entire blockchain.  My guess is that the first blkfile (128 MB) stores 101,000 blocks.  Armory believes that's the only file you have on your system.  Can you please post the listing of your .bitcoin directory (or C:\Users\username\AppData\Roaming\Bitcoin)?  Inside that directory is a "blocks" subdirectory (if you are using 0.8).  If that directory is there, can you post that too?

Finally, can you send me the logfile?   You can export it from Armory (File menu), or copy it from .armory/armorylog.txt.  Feel free to browse it for any sensitive information to calm your nerves, but it never includes any security-relevent information (but it may contain evidence that you own certain addresses).

On one of my computers, armory only loads up to block 101,000.  It will scan the blockchain and eventually say that Armory is "online," however it won't load past block 101,000.  As such, it states that all of my wallet balances are zero when they clearly aren't zero as indicated by my other computer which is also running armory with watch-only copies (the other computer is intended to be an offline computer, however I'm getting used to armory so I'm making 100% sure that I'm familiar with it and that everything checks out before I dump everything into cold storage).

Has anyone else had a problem getting Armory to recognize the entire blockchain?

Hi K1773R and etotheipi,
I couldn't find the file bitcoin.conf so I created it and added it to the Bitcoin folder with  "listen=1" as its only content.  I also made the changes in the Armory shortcut
target.  Bitcoin still works but Armory still stays in the Offline mode.  Any suggestions?

You're right!   It doesn't use the https links!  It looks like there's no problem simple swapping http for https, so I'll go back through my scripts and make sure that's done in the future.  Nice catch!