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

Best I can tell the file doesn't exist.

That command gives me nada.

Line 15 is what makes this makefile work regardless of what python version you have installed.  Unless you have a non-standard python installation.

What shows up when you type "ls -la /usr/lib | grep libpython"?  

You can change line 29 to just point to whatever .a or .so is there.  

For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.

No dice.

I'm confused by what should be added/replaced. This is what my Makefile looks like:


Can you give me a replace code with code for simplicty?

No that's not it.  It's a one-line makefile fix, but I needed someone who had this problem to help me test the fix for it.  I'll commit something to the "armoryd" branch (which is my current development branch), in about 10 minutes.  If that doesn't work, I'll just tell you how to fix it

    SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
   STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"

   ifneq (exists, $(shell [ -d $(STATICPYTHON) ]  && echo exists ))
      STATICPYTHON = "$(DEPSDIR)/lib/libpython$(PYVER).so"
   endif

install python?

Fedora 64 bit make command gives me this error. I know this issue was addressed by mac osx builds, but was it ever addressed for linux builds?

@wachtwoord
The alternative you describe is really not much better than just maintaining an encrypted wallet on your hot computer.  What it prevents is someone who has gotten remote access to your machine and manually digging around your filesystem looking for wallet files.  That's not to say that such things don't happen, but I believe the real threats are viruses that get on your computer and siphons off data and send it back to "home base" when it finds it (it will farm the data and send it back the next time it's online).  In this case it probably doesn't even have to send any data back... it just reads your wallet when decrypted and creates a transaction sending all BTC to its owner the next time it's online.

Any computer with access to the internet is vulnerable to these viruses.  You can get them from various exploits usually relating to your browser, or opening PDF/.xls documents with embedded exploits, etc.  However, in order to compromise a truly-offline computer, there's a couple orders-of-magnitude more work for the attacker to do.  They must (1) find a way to hide data on your USB key that (2) exploits an auto-run vulnerability when plugged into the offline computer, and then (3) be able to automatically find the data and copy it back, hidden, on the USB key to get it back to the offline computer.  And these exploits are much more complicated when they don't even know what OS the offline system is.  And if I can find another way to transfer data between systems not using USB keys, then this would even an order of magnitude better...

I would look into this idea posted by N.Z..   It's a bit more work but is definitely a very reasonable solution for a single-computer setup (in fact, I've been thinking about bundling the tails packages like N.Z. suggested, to make this easier).  This means that your wallet only ever touches this sandbox that has no access to internet, and is reset to default configuration on every boot.

As for question 3 (paper backups), you just said in question 2 that you believe flash storage is frail.  This is exactly why you make paper backups.  If you print a paper backup and put it in a safe-deposit box or fold it into a book on your bookshelf, it will still be readable 20+ years from now . It doesn't even have to survive "well", as you could pull the data out of a terribly-faded copy with a bit of work.  I mean, you've seen books that are 50+ years old and their pages are still readable.

Now compare that to any kind of digital media.  You can drop a flash drive, or sit on it or bend it, or put it too close to a magnet, or it just decays and it's no longer usable.  What's your confidence level that even a well-treated USB drive sitting in a metal box will still work 5 years from now?  20 years?    Even CDs and DVDs have expected lifetimes of 2-10 years, but that varies widely depending on lots of factors.  With the paper backup, unless it physically burns to ash, you know it will still provide the data you need to recover your wallet in 20 years.... probably much longer than that.

I'm not sure I understand what you tried.  Were you trying to test creating unsigned transactions and then sign and broadcast with Armory?...

edit3: I had a crack at getting the listtransactions data for the various scenarios you describe (and thus the 'way it works'), however I couldn't get any results. Frustratingly, I got raw transactions to sign (which is the second-last step of many) and then the last step is to broadcast the transaction, but my transactions were always getting rejected. I've got my progress thus far well documented and is definitely repeatable so I might try to work it out later in the week. It's worth asking on the development subform for clarification on the way the listtransactions call works, they will hopefully be able to answer it. Anyway I was creating raw transactions to match your scenarios based off this guide and testnet-in-a-box - https://people.xiph.org/~greg/signdemo.txt