Topic: Armory - Discussion Thread - page 179. (Read 521829 times)

Ahh.  All that python dependency stuff should be a non-issue, now.  And it wouldn't have been issue if you were using Ubuntu 10.04-32bit (which is what I made the offline-bundle for), but I recognize some users will use different distros and/or want to compile it themselves.   However, even that has been improved with static compiling of python into the C++ utilities. 

When I do the next release, I'll make a couple extra offline bundles -- one for 10.04 and 12.04. And I will include all the packages you need to compile it, not just install it. 

it was discussed here back when I did it. I think first it was wrong python version, then it was mainly wrong glibc version linked against the swig stuff vs. the version on my ubuntu. I ended up using a version of cppForSwig I compiled on a different host. Read post https://bitcointalksearch.org/topic/m.965679 and onwards for more info.

Molecular,

What was the cause of the problem here?  If you use the supplied "offline-bundle", it takes about 30 seconds to install on an offline Ubuntu machine (double-click InstallAllDeps.sh, and you're done).  If something wasn't so easy, then I'd like to know how it can be improved.  I expected the offline machine to be the easiest...

Damnit, no dancing naked on Mars in sulfur rain? Ok, I change my mind: beam me naked to any place that has bitcoin infrastructure, drugs postal service and hookers.

The average temperature on Mars is -55 C (-67 F) so I advise wearing one of these: Omega down suit

While I love armory, I disagree on your point.


is what I do to generate private keys for cold storage savings. Import that into armory (on the offline secure machine) and generate a watch-only copy of the wallet for use on insecure online machines to watch the funds still being there. Delete the real wallet again, it's not needed (this whole armory-step could be skipped, it's merely for the convenience of being able to monitor savings and have an easy-to-access list of the addresses. the address can be computed from the private )

To get to the funds, use a copy of StrongCoins offline transaction generation/signing javascript code (generate tx (moving all funds from one of the savings addresses to an address in my everyday wallet) on insecure machine, sign it on the secure always-offline machine and inject it into the network using the insecure machine again (shuffling data using a usb stick))

https://www.strongcoin.com/blog/the_easiest_way_to_create_secure_offline_bitcoin_transactions

took me some balls to do it, but now my savings are secure from both theft and loss in my brainwallet as long as I can manage to remember the passphrase.

One can also do it with armory instead of strongcoin-offlinetx-script, but firefox+strongcoin-offlinetx-script seem simpler to install onto an offline machine than armory (took me multiple sessions of 1-2 hours to get armory onto the offline ubuntu machine).

I know it would be possible to integrate private-key-import by sha256(passphrase) into armory but I agree with etoteipi that it should not be standard practice, because people can't be trusted to choose good passphrases. However, I like this method because sha256 implementations will always be available and nothing else is needed (except some bitcoin-related infrastructure, which will also be there unless my bitcoins are worthless anyways). Regarding the injection of the signed tx into the network: assuming bitcoin remains opensource, this can rather easily be coded up by someone or myself in case push comes to shove and no service for this should exist... or: if available, I can still use armory to do everything I just described doing with strongcoin-offlinetx-scripts

So go ahead, beam me to Mars naked, I'll have my coins as long as there's bitcoin infrastructure and some air to breathe

Thanks for the suggestions.  The small usb idea, was just for me, not something I was advocating for all armory users to mess with.  Don't get me wrong, I really like Armory.  After spending a long time looking at alternatives, I decided Armory is the closest alternative to a perfect solution that is out there.  Most of the paper wallet solutions available, really are not truly "offline" solutions to me when the private keys have to, eventually, enter something that runs online where, practically speaking, the environment cannot be guaranteed to always be 100% secure.  Only using the paper wallets to send once & then sending the change to a new one, was one idea, but that seemed like it would get confusing to me after doing it for a while.  Armory is the only easy-to-use solution I could find, that doesn't have you trusting an online environment, or relying on a web page that might not be there someday, to transmit the signed transaction.

Having thought about the weakest point though, I would like armory a little better if it printed OCR codes to return the signed transaction to the online wallet to transmit.

For a USB, I'm happy trying a solution that will work for *most* transactions I might make, maybe enlarging the partition or moving to new keys with no transaction history, as my previous transactions eventually grow too long.  I will give it a try.

This is definitely a non-perfect situation, but it's pretty damned good given the usability requirements.  The process is already complicated for some new users, and they may not yet fully understand what's going on.  I'd rather them use offline wallets with a USB key than not use offline wallets at all (which is a significant risk if it's too complicated).  In that sense, everyone understands USB keys, so it serves its purpose well, and if you take precautions (like disabling USB autorun services, etc), it's very safe.

If you are ultra-paranoid, one thing you can do, is buy a USB key that has a write-protect switch.  Write the transaction to the USB key (which may be many kB), then turn on write-protect and insert it into the offline system.  If you sign the transaction and observe the difference between the original and the signed version, it's only ~140 bytes for each input at the bottom of the TxDP: (in bold)


Luckily, Armory wallets have been the same since day one, and will continue to support the same deterministic structure even with the new wallet format coming up.  As such, any version of Armory since January will be sufficient at producing any number of keys from any Armory wallet you've ever created.  Even if support were to disappear, you'll be able to get those back with any version.  

As for the small USB key partition:  I like the idea a lot better if there was a way to bound the transaction size.  Unfortunately, these sizes are highly variable -- since I need to store previous transactoins in the TxDP (what is sent to the offline computer) there could be 100 kB in a single transaction.  However, most transactions, for simple users, will only include a couple inputs and will only be a few kB.  As such, the gap between smallest and largest is big enough that something sufficiently advanced could hide there

Passing an unwanted guest to the offline wallet and back again over the USB key, seems like the one main vulnerability of Armory.  I was thinking of re-partitioning an old USB flash drive to be just large enough to store most transactions one might make to/from the offline wallet. 

I was wondering if that sounds like a very good idea and, if it does, if the developer had any idea about how much space might be a good compromise between usability (key not usable if too small) and enhanced security (space for unwanted guests if key partition too large).  As the wallet is offline, I don't anticipate ever sending to multiple addresses, or having especially long blockchain entries.  I have imported private keys for this just in case anything were to go wrong with the armory wallet or if support on Armory were to end abruptly.

Hi watchwood,

(1) So far, even while Armory has been in alpha for six months, I have received no reports of anyone losing money with Armory.  Ever.  I spent days testing and ironing out the wallets when I started, and there's never been a hint of a problem!  Even I am impressed that the wallets have been so reliable through the infancy of the program.
--Offline wallets are the holy grail feature, and they work.  Even though they use USB keys, they are orders of magnitude better than regular encrypted wallets.
--When you do maintain encrypted wallets online, Armory uses a scrypt-like key-stretching function to make it difficult for someone to brute-force the password even with GPUs.
--If you make a paper/digital backup, all coins are always recoverable (after all, I think HDD failure is a bigger risk for most users than theft).

(2)  The digital and paper backups are essentially the same.  They are deterministic wallets and all keys ever produced by them are recoverable from the first address & chaincode in the wallet.  The only caveat is imported keys, which will have to be backed up separately.  However, you can "Backup Individual Keys" in order to create a unified backup of all imported addresses.  You can even use it to get the private keys of all your addresses (used so far) in case you want to import them into another program/servicce.

Thanks for your interest!  I'm always happy to answer more questions about Armory

Hello, thanks for creating Armory looks pretty damn good so far. I wanted to try it out because I am looking for a bit more freedom than the standard client provides and it seems like the software is getting more secure. I have two questions:

1) How would you rate security (i the sense of absence of bugs which could cause a user to lose money) in relation to the default client? I am contemplating which client to use for Walets containing the majority of my Bitcoins

2) I have created a new wallet and made a digital backup. Am I correct in understanding that this backup will be sufficient always and never has to be recreated due to the deterministic nature of the armory wallets? (For the default client I have recreated my backups monthly to avoid losing coins sent to newly generated addresses).

Thank you

Fwhew!  It's so nice to hear that at least one person is not having a problem with Armory!  A lot of Armory problems reported in the last couple weeks and I've been swamped at my real job.    So, I won't get to address the major issues for another couple weeks (such as switching Armory to maintain its own blockdata files).

By the way, I went down to 30 hrs/week after crowdfunding back in March so that I could work on Armory more.  And I will be back to that in a month.  Until then, I get to work 50+ per week and only get paid for 30   Armory development is slow right now...

I just looked at the export-tx-history code and it does seem to be an error.  Sent-to-self transactions are not reflected properly in the .csv.  That should be an easy fix.

Also I am finally able to reproduce the version-check-freeze.  And so far nothing I do fixes it.  It must be related to github, since urllib2.urlopen works with google & microsoft.com fine, despite freezing for 4 min on github... I'll try to host the version check file somewhere else and see if that fixes it.  Hopefully tomorrow I'll have a re-release of 0.82.1 with a few other bug fixes too, and then I'll dig into the segfaults...

Hello etotheipi,

I'm testing the 0.82 and currently found no real bug. There's only one minor tiny improvements that could be made:

I transferred some coins from one address to another in the same wallet. Armory understand this is the same wallet and so balance doesn't change.

But when I export the CSV, the transaction is set in the "Total credit" column only, with no mention of fees paid. So it looks like we received the whole amount instead of sending and receiving it at the same time. Could make the column "Total debit" mention the debit as well?

Thanks a lot for your great work

I finally got a crash from the version I built with debugging symbols.  Here's the backtrace:


I'll leave the gdb session running, so if there are any commands you want me to type at it, I can do so.

strmPtr=0x4 doesn't look good though.  Pointers usually have high values, not 4...

Do you have a 'suppressions' file from when you ran it before?  There are usually a bunch of memory read/write errors in the libraries you link with which need suppressing before you can notice the errors in your own code.

Oh good call!  I haven't run valgrind on the C++ codebase in months!  Since I've changed so much of the underlying code since then, I should probably check it again.

I hope you find something.  I haven't yet experienced any crashes, but many other users have, and I'm hoping they're all related to the same thing...

Incidentally, when I modified the Makefile in cppForSwig/ my editor complained that lines 23 and 73 were "suspicious".  Both those lines contain only a single tab character.  Tab is significant in Makefiles, so it's probably better to delete those two tabs.

I've just been doing "gdb python" then "run sample_armory_code.py".  That should be enough, right?  gdb's "run" command takes arguments and passes them to the process it's debugging - in this case "python".

As predicted the crash is no longer happening of course...

When I get my faster laptop back from having it repaired I'll try running it using valgrind.  That usually finds the source of intermittent crashes.

It actually usually is useful, but you might have to compile Armory in debug mode (I manually modify the Makefile [at the top] because I do this so rarely).  And then you have to run "gdb python" because you actually have to debug python in order to hit the stack trace.  So you "gdb python" to get into GDB.  Then you type "run" to start debugging python.  Then you type "import sample_armory_code".  Then the stack trace will extend into the C++ code.  Not to mention, once it's compiled in debug the C++ will provide a little more output.

I have been overwhelmed with work-work, and Armory has fallen in priority this month.  This will settle down in a couple weeks (my real job rarely gets this intense) and I'll be back to part time like before.  So all of you digging into these things for me is fantastic!   Thanks so much!

I ran my modified copy of sample_armory_code.py twice today.  Both times it failed with "Segmentation fault".  I've not modified the C++ code at all.

I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening.