Hi -

I am using Armory 0.94 on two computers (online/watching, and offline). I have a few wallets, and each wallet contains some addresses - and each address contains some coins, received a few months ago.

On the online machine, Armory shows the correct available BTC balance total summarizing ALL the wallets - in the lower-right corner of the main screen.

And Armory also shows the correct available BTC balance available for EACH separate wallet (as a whole) - in the list on the upper-right of the main screen.

However, when I double-click on an individual wallet, it does NOT show the INDIVIDUAL ADDRESSES (and their individual balances) in that wallet.

Instead, my online Armory is only showing one very OLD individual "test" address for each wallet - which received a tiny transaction about a year ago. It does not show the more RECENT individual addresses in the wallet (and their balances), which received transactions a few months ago.

By the way: These are not "restored" wallets - they are simply the original "watching-only" wallets, imported from the offline machine.

In other parts of the Armory UI on the online machine, each TRANSACTION is listed correctly - including the receiving addresses in each individual transaction.

So Armory clearly "knows" that these addresses have been generated for a particular wallet - and it "knows" how many BTC are in these addresses.

So why is my Armory online machine not displaying these addresses and their balances in the Address List in the Wallet Properties window?

ASIDE: I understand there is also a method for generating more look-ahead addresses for a wallet, in Expert Mode. But I don't think I should have to generate any "look-ahead" addresses using this method, because it seems that each "watching-only" wallet should already "know" that it should display those addresses which were generated back when the wallets received funds. Plus it also seems that if I were to generate any more "look-ahead" addresses now, Armory would probably "skip over" the addresses which it remembers having generated a few months ago (ie, the addresses which contain some coins and which it is mysteriously not displaying in Wallet Properties now), so I doubt that generating more "look-ahead" addresses would solve this problem.

Thanks for any help!

Hi -

I think Synereo is very promising, mainly because of the involvement of Greg Meredith - who I consider to be one of the best brilliant mathematicians around, combining a deep understanding of math with a very accessible communication style.

I was thinking of buying some AMP now in the sale from Synereo.

I had some questions:

(1) Can I simply purchase some AMP from an address in my Armory wallet - by sending some BTC to Synereo's AMP sale address? (Of course I control the private key for this Bitcoin address.)

(2) How long will it take me to receive the AMP from Synereo at my Bitcoin address?

(4) After I receive the AMP (to the address where I sent my BTC from), then of course I cannot "see" the AMP in my normal Bitcoin wallet - but I could (a) "see" my AMP on omniwallet.org, and (b) download a desktop wallet from omniwallet.org, and also "see" my AMP in that wallet.

I assume I would not need to sign up at omniwallet.org in order to do (a) - I would simply be using some sort of "blockchain explorer" which they apparently have on their site.

(5) What are the expectations / guarantees regarding the eventual total maximum coin issuance of AMP?

This Google Docs spreadsheet:

https://docs.google.com/spreadsheets/d/1r1G-ROS4vgHK84qfn1CBIxuXZQCCvIicCTQSxW1T_mo

states there are currently 929,291,063 AMP in existence.

Is there a guarantee that this is the maximum or "cap"? Or could more AMP be issued?

Conversely, are there some plans regarding more AMP which are intended to be "burned"?

(6) In the case where 929,291,063 AMP really is asserted to be a maximum or "cap": Is there some way to formally verify this assertion of a "cap"? For example, maybe there is some published source code specifying the long-term AMP issuance algorithm?

Thanks for any help!

Wow, I was reading up on btcd today and now I heard about Decred. Very interesting project!

(I was getting very frustrated having only one implementation for Bitcoin from Core / Blockstream so I was researching alternative implementations, was even thinking of rolling up my sleeves and writing an alternative implementation for Bitcoin in another language, perhaps in some more "academic" language oriented towards algebraic specification and theorem-proving such as Maude for modularity or ATS for performance. I had heard that the code for btcd was much better-organized, so that's why I was looking at btc, as a way to try to get a good example of modular code for a Bitcoin fullnode.)

And somehow while researching btcd I stumbled across Decred, which apparently has some of the same devs as btcd.

Decred sounds great! I expect that given the experience of the Decred devs with the btcd implementation, Decred could become an important cryptocurrency. I especially like the idea of "baking in" the governance into to the blockchain itself - as we are seeing that Bitcoin's governance-by-reddit-posts-and-github-ACKs is proving to be, shall we say, somewhat "dysfunctional."

I hear there was an airdrop which ended Jan 18, so I'm bummed out, did I really miss the airdrop??

I heard that up to 5,000 verified people could receive the airdrop, so far about 3,244 got verified... so please let me know if there's room for any more people to participate in the airdop, I'd love to be involved in this exciting project!

The programming languages I tend to use are functional (ML, Haskell, etc. - more in the area of theoretical computer science, algebraic specification languages, theorem proving, dependent types, etc.) although of course I can also read C++, golang, etc.

I'm located outside the US, but I studied previously in the US.

Hoping to find out any way I could get involved with Decred, and if there is any chance of the airdrop still adding some additional verified people!

Well, there might be a few more specific questions - eg, regarding file names and directory names.

(1) What if the daemon for Bitcoin Classic has a name other than 'bitcoind'?

(2) What if the home directory for Bitcoin Classic has a name other than '~/.bitcoin/'?

Could everything be handled by simply going into Armory File > Settings and telling it to use non-default filename / directory name?

Or perhaps the user could simply rename the Bitcoin Classic filename / directory name to match the Qt names?

Or perhaps Bitcoin Classic will actually be released using the same names that Qt used?

Thank you for these answers. So I'm encouraged that basically you're saying it's doable, at least in concept. I don't mind a few extra steps.

Some clarifications:


I don't see there could be more risk of them being stolen.

I'm planning on exporting the keys from Qt and importing the keys to Armory as follows:

(1) Copy the Qt wallet.dat into the offline machine, fire up Qt, and use the command-line interface in Qt to export the private keys.

(2) Import the private keys to Armory - also on this same offline machine.

So... How could anything get stolen in this scenario?

Oh, I think I get what you're saying the risk could be: someone else could have a copy of those private keys from the Qt wallet. But it's been under my exclusive control this whole time, and besides, those private keys are only going to be used for a short time (in the new Armory "temp" wallet). Their funds will be immediately sent to the Armory "permanent" wallet, in step (2)(d) of my original post.


This is actually a really old wallet - I think it's about 3 years old. So I think it doesn't use compressed keys.

Possible alternative:

I guess I could also simply sign a raw transaction from Qt itself and then broadcast it to my new Armory offline "permanent" wallet, from a site like blockchain.info/rawtx. This would obviate the initial step of importing to Armory, into a "temp" wallet, as mentioned in my step (2)(a).

However, since I'm going to have to learn anyway how to offline-sign and broadcast transactions in the future using Armory, and since I haven't learned how to do that yet using Qt, I figured I might as well just get the private keys into Armory, and then have an all-Armory all-offline solution for getting the funds from Qt to Armory, without having to learn how to offline-sign raw transactions from Qt.

I would only do this alternative (offline-sign a raw txn from Qt, and broadcast from blockchain.info/rawtx) if the keys from Qt actually do turn out to be compressed. But this wallet is really old, so I think they're non-compressed.

Questions:

(1) When I import a private key from Qt to Armory - the key (along with its funds) still also technically exists in Qt wallet.dat, right?

This way, if I make some mistake on the import to Armory, then my funds are still ok in Qt, assuming I don't lose my Qt wallet.dat file?

(2) I want to avoid "sweeping" - which I can't figure out how to do fully offline.

So I want to do as follows:

(a) Import private key from Qt to a "temp" Armory wallet "TempWallet" (offline of course).

(b) Create another, separate "permanent" Armory wallet "PermWallet" (also offline).

(c) Import private key from Qt wallet.dat to Armory wallet "TempWallet".

(d) Offline-sign & online-broadcast a transaction (using the normal procedure) sending funds from Armory "TempWallet" to Armory "PermWallet".

Would this work?

Remark:

I know the above approach would take slightly more steps, but at least I'm comfortable with it, since "import" + "offline send" seems like it could be done totally offline, versus "sweep" which seems like it combines an "import" and an "online send".

Apparently, I wouldn't have control over how the "send" part of the "sweep" is performed - ie, I couldn't do the "send" part of the "sweep" offline.

So I want to do this slightly longer approach, so I can avoid putting wallet.dat back online now even briefly in Qt, and so I can do the import from Qt to Armory offline, and do the send in Armory also offline.

So everything would be completely offline now.

Does this approach make sense?

Thanks for any help!

PS - I did also post the same question a few weeks ago - but I think my post was too long (and confusing), and also I didn't really understand the answers - sorry!

https://bitcointalk.org/index.php?topic=1251427.0

Wow, I had no idea I was running a full node!

I thought I had to do some extra steps like unblock port 8333.

It's kinda cool to know I've been running a full node this whole time, without actually realizing it.

Hi I'm running Armory on two machines, online / offline, for cold storage.

I will be traveling places where there is almost no internet - but maybe there will be a few internet cafes around with so-so connectivity.

Could I set up an online Debian machine on a server such as Amazon AWS, and just take my offline machine with me, and then sign transactions on the offline machine, walk them over to some kind of internet cafe or whatever, where I could ssh in to my online machine and send the signed transaction to it?

Would that be risky during transit because I'd be sending a signed transaction across the internet using ssh? Maybe I could use some kind of encryption?

The remote online machine itself would be running on VPS somewhere like Amazon AWS, with plenty of bandwidth to keep its copy of the blockchain up-to-date.

The remote online machine / VPS on Amazon would also probably be "headless" and it wouldn't have a desktop GUI such as gnome or xfce - which would actually be fine because I believe it would take much less bandwidth to talk to a remote server via ssh from some internet cafe if the whole thing is done via command-line instead of GUI.

So I guess there's 5 questions I have here:

(1) Does this whole approach even make sense from the perspectives of security, practicality?

(2) If this is do-able, would I need some kind of encryption to use when sending a signed transaction from some internet cafe to the remote online machine via ssh?

(3) Does Armory have the kind of command-line interface which would allow doing all this with no GUI the remote online machine running on Amazon AWS?

(4) This could be the clincher question: What kind of software would I need to be running from this internet cafe?  I was hoping I could just quickly install Putty on some Windows machine in an internet cafe and do everything via ssh - but maybe I would need a local machine running a full copy of Armory? In that case, I could probably use yet another machine: it could be my existing online Armory machine, but because I'm travelling and it's been offline for weeks it would not have an up-to-date copy of the blockchain - but it would still have all the functionality of Armory, the python-qt GUI, etc. Then it seems like I'd be trying to create some sort of hookup between:

- the formerly online Armory local laptop with the outdated copy of the blochain plugged in or wifi-ing in at an internet cafe, and

- the up-to-date currently online remote server on Amazon AWS.

... also using a signed transction from the offline machine.

(5) I think I saw a website once, I think it was a page at blockchain.info, where you could also do something like "upload a signed bitcoin transaction". Is this browser-based method of signing a transaction on a site like blockchain.info compatible with the kind of signed transaction produced by Armory? If so then maybe I could skip all of the above - no VPS on Amazon needed, just keep my Armory offline machine with me and sign transactions from it and submit via any web browser?

Thanks for any help.

By the way, I asked this same question a few weeks back on this forum and nobody answered:

https://bitcointalk.org/index.php?topic=1273673.0

Is this a totally crazy question maybe??

Hi -

I have Armory / bitcoind running on an online Debian machine, and another Windows machine using the same internet connection.

Today the Windows machine couldn't connect to the net (pinging was giving a time-out), so I ran 'netstat -plan' on the Debian machine, and it showed about 250 lines of tcp connections apparently involving bitcoind and python starting with:

... 250 more lines

I can send the rest of the lines of output - mostly involving listening at foreign address at port 8333 or listening on localhost at port 8332.

(Would I need to obfuscate any of the foreign IP addresses or ports first before uploading the rest of my 'netstat' output, in order to protect my or anybody else's privacy? I'm not running Armory/bitcoin behind Tor yet, but I would like to do so in the future.)

I've never really understood what any of this output means, in the case of Armory and bitcoind.

In particular, I've never known if hat I'm running is a "full node" or not. I've heard you had to "open port 8333" for that - I'm not sure if that would involve some software-based firewall on my Debian machine, or maybe messing with something in the Internet router.

I've set up iptables on remote Linux servers before, but this local Debian machine only has a minimal install (bitcoin, armory, a browser) and I didn't set up iptables on it so I guess there's no firewall on it yet?

Can any of you guys here tell me based on my 'netstat' output whether I'm running a full node? (Again I can send all 250 lines of the netstat output if needed, also with IP addresses obfuscated if that's recommended, I have no idea.)

Note re: the router: I previously was using a really configurable Internet router which ran that opensource router firmware OpenWRT - I totally suck at Internet routing despite having read some big-ass O'Reilly book about TCP/IP once which I still have somewhere here - much to my embarrassment I had to hire some geek kid to set up that fancy router for me a few years ago, just for a Windows and Linux machine, no Bitcoin at the time, but I think the main reason I got that fancy router was because I wanted to do a nice setup later with it to run Bitcoin behind Tor - anyway this kid hemmed and hawed and made a bunch of diagrams for half an hour and finally configured the router for the Windows and Linux computers and charged me 100 bucks and then a few months later that whole fancy router setup stopped working so I went back to using the ancient crappy standard modem-router from the phone company here. I want to re-install the nice high-end router with OpenWRT again soon, by myself hopefully this time, once I have to patience to read up on it all again.

Note re: my internet speed: I live in a really under-served area where I have to watch Youtube at 144 or 240 or it freezes up and sometimes my Skype freezes up, so I don't think I should probably be running a full node - and I actually have never known if I am or not, but my Armory always says it's up-to-date, although it can take a couple hours to catch up again if it's been off for a few days.

Thanks!

TL;DR:

Can I use Armory Offline / Online (cold wallet):

(1) where the ONLINE machine is on a VPS (eg AWS, Digital Ocean, etc.); and

(2) with VPS + Tor or VPN to broadcast txns anonymously?

(3) Would there be any security issues using ssh-tunneling to send a signed transaction from a local online machine to the remote online machine on the VPS?

---

I am interested in using Armory for a cold wallet (2 machines: 1 online, 1 offline).

However, I travel a lot and I don't always have decent internet (ie, sometimes I'm out in the sticks with very slow internet, where I can't even use YouTube or Skype - so it would not be possible to keep my online Armory machine up-to-date with the multi-gigabyte blockchain).

So I have the following questions:

(1) In this situation, would it make sense for me to set up my ONLINE machine on some remote VPS - virtual private server (eg, Amazon AWS, Digital Ocean, Linode, etc.)?

(2) Could I use Tor or VPN on the remote machine (on a VPS)?

(3) Would there be any security risks involved when sending the signed transaction, presuming ssh'ing in to a remote desktop (from a third machine, which would be local and running Debian)?

---

I have managed to get a test configuration set up on two machines (online/offline), using Debian Jessie 8.2 + xfce, with Armory 0.93.3. {Footnote 1}

I'm still a little unsure of the exact sequence of "sneakernet" steps involved when using Armory Offline / Online. I believe it will go like this:

(1) On the ONLINE machine, start to create a transaction (spend).

(2) Copy it to the OFFLINE machine to be signed.

(3) Copy the signed transaction back to the ONLINE machine, and broadcast it.

---

Now here's my main questions:

(1) If I'm doing the above steps where the OFFLINE machine is local (my laptop) and the ONLINE machine is remote (on the VPS at Amazon, Digital Ocean, Linode etc.) then I guess I'd need to be able to have remote GUI / Desktop access to the remote online machine.

So in my case, I'd want to use Debian + xfce remotely. It sounds like people are actually able to use Debian + xfce remotely:

https://www.google.com/search?q=debian+xfce+remote

Is this feasible / sensible with Armory? (I'm worried there might be some kind of "latency" issues, or maybe issue communicating with bitcoind via rpc or something.)

By the way, I would have yet a third Linux box which I use to ssh in to the remote ONLINE Armory box on the VPS. I'm not sure what kind of security would be necessary on that machine - as it would be transamitting a signed transaction over ssh.

(2) Would it make sense to try running the ONLINE machine (which is on the VPS at Amazon, Digital Ocean, Linode etc.) behind Tor?

In general, I want to use Tor when transacting with Bitcoin - I'm just unfamiliar with the way Tor might play with a VPS.

Or, is there some way of doing VPS + VPN? I've set up VPSes on Amazon, Digital Ocean, Linode - I just don't know if there's also a way to use a VPS "anonymously", either via Tor or VPN. (I guess if I use a VPN, I'd also want to pay them anonymously using Bitcoin, instead of with my credit card =).

(3) Would there be any security risks involved when sending a signed transaction from a third machine - presuming tunneling via ssh to a remote Debian xfce desktop on the Armory ONLINE machine running remotely on the VPS?

Thanks for any help!

---

{Footnote 1} It was difficult getting all the dependencies correct on the offline machine, but eventually I managed to do it, by looking at what apt-get put in /var/cache/apt/archives when installing from scratch on a fresh Debian 8.2 Online machine, and then using those as my "Offline Bundle" on an identical fresh Offline machine.

There were two additional .deb files involving PyQt which initially caused error messages while doing 'dpkg -i' against my home-brew "Offline Bundle", which I simply downloaded separately from a Debian repository and added to my home-brew "Offline Bundle" specific to Debian 8.2 Jessie + Armory 0.93.3. Then it finally worked.

- I adopted this "home-brew" approach because most of the documentation and workarounds which others had posted regarding their particular "Offline Bundle" solutions were either out-of-date, or simply not compatible with my particular Debian 8.2 setup.

- I preferred Debian over Ubuntu because Debian seems to come pre-loaded with less or no consumer-oriented crapware.

---

Hi -

Sorry this message got kinda long, but I have lots of questions about tiny details, and I don't want to screw up my security! I tried to split everything up into numbered items to make it clearer.

What is the best way to migrate from bitcoin-qt to Armory Offline, while satisfying the following 3 Requirements:

(1) never put the old wallet.dat from bitcoin-qt into an "online" machine (i.e., don't use the old wallet.dat file with bitcoin-qt online, and don't use it with Armory Online)

(2) the final destination of the coins must be a HD (hierarchical deterministic) wallet

(But if it is necessary to do an an "extra" transaction to move the coins through a "temp" wallet which might be non-HD, then that would not be a problem.)

(3) use multi-sig

---

I have read several explanations of the difference between "sweep" or "import":

https://bitcointalk.org/index.php?topic=966137.0;wap2

https://bitcointa.lk/threads/sweep-vs-import.190631/

But I'm very paranoid and I want to make sure I really understand the difference between the two, and how they apply to this particular use case (especially requirement (1) above - to avoid putting the old wallet.dat into an online machine).

---

How about the following approach, would this be good?

(1) CREATE a new wallet W-NON-HD-TEMP-IMPORT in Armory on the Armory Offline machine, and IMPORT (don't SWEEP) the private keys into this new wallet.

This can be done entirely offline, right? No need to run bitcoin-qt online, and no need to use Armory Online - just do everything on the Offline Machine:

  (a) Export the private keys from wallet.dat, using the command-line interface of bitcoind

  (b) Import the private keys to wallet W-NON-HD-TEMP-IMPORT in Armory Offline - on this same permanently offline machine.

From what I understand, this might be equivalent to what a "sweep" actually does - but I don't mind doing it like this myself (and in fact, I suspect that doing it like this myself may be necessary in order to satisfy my requirement (1) above: never put the old wallet.dat from bitcoin-qt into an "online" machine).

Note: We will be using W-NON-HD-TEMP-IMPORT only as a "temporary" (non-HD) wallet - from which to send the coins using offline-signed transactions to the "permanent" wallets (which will be HD), to be created in the next step.

CONCERN: I'm still concerned about "change addresses" that might be generated during these "sends" from the temp non-HD wallet.

Maybe I need an 2nd "temp" wallet which is HD? So I would go in the following sequence:

  wallet.dat  =>  W-NON-HD-TEMP-IMPORT  =>  W-HD-TEMP-IMPORT  =>  HD wallets

where each "send" from the non-HD temp wallet W-NON-HD-TEMP-IMPORT to the HD temp-wallet W-HD-TEMP-IMPORT would use all the coins from the source address in the non-HD temp wallet?

This would serve two purposes:

(a) Get all the coins out of a non-HD wallet, into a HD wallet

(b) while using up all the coins from each source address during each send - so there would be no need to generate any "change" addresses during the "sends" from the non-HD wallet.

Of course, using a 2nd HD temp wallet like this may be overkill - if we assume that I'm only going to need the non-HD temp wallet for a few hours or a day, while I'm totally emptying it into the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 etc. Even a non-HD wallet is able to generate change addresses, correct? It's just that for a non-HD wallet, these change addresses can't all be determined in advance based on a 72-letter code, correct?

(2) CREATE some new, empty wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 etc. on the Armory Offline machine. These will be HD wallets! So you can back them up to paper now.

(3) On the Armory Offline machine, create some transactions which send coins:

 - FROM wallet W-NON-HD-TEMP-IMPORT (the temporary, non-HD wallet into which the keys from the old wallet.dat from bitcoin-qt were imported without touching an online machine during that process),

 - TO the new, empty wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 (which are HD)

(4) Sign these transactions on the Offline Machine, copy the signed transactions from the offline machine to removable media, put the removable media into the online machine, and then broadcast the signed transactions to the network from the ONLINE machine.

---

Aside re Paranoia: If I'm really paranoid, could I use a CD for the removable media, instead of a USB drive?

I sometimes hear of exploits in USB drives, so CDs seem safer, since they seem more "inert".

I don't mind wasting a few cents on a fresh blank CD every time I want to copy a signed transaction from the offline machine to the online machine.

What I want to avoid is plugging the USB drive into the online machine, and then into the offline machine: this seems like a potential physical path to allow a virus to hitch a ride on the USB to copy itself from the online machine to the offline machine.

The only media which have ever been inserted into my offline machine are:

(a) the Debian/Ubuntu install DVD, and

(b) a CD containing:

  - the bitcoind / bitcoin-qt binaries

  - the Armory *.deb file

  - plus a bunch of other *.deb files for Armory's dependencies for my particular versions of Debian/Ubuntu & Armory

---

Aside re Dependency Hell:

By the way it took me several days to determine exactly the correct set of *.deb files for these dependencies, since most of the documentation out there for this is outdated, and so I went through several days of "dependency hell".

I think I managed to figure out the dependencies by doing:

(i) Install the Armory deb using apt-get

(ii) Check in the directory /var/apt/cache/... to see what debs it downloaded - these are the dependencies, to use to make your own Armory Offline Bundle, compatible with your version of Ubuntu/Debian.

(iii) On the Offline Armory machine, try running dpk -i against these *.deb files, and then try running dpkg -i against the *.deb file for Armory.

(iv) In my case, I still got error messages for two missing *.deb files which were dependencies for Armory, so I got these final missing *.deb files from a Debian/Ubuntu repository online, and added these *.deb files to the set used in (ii) above, and re-ran dpkg -i against these *.deb files, and then against the Armory *.deb, and everything finally worked.

Yeah, I've basically been doing this for several weeks, on my own, repeatedly re-installing Debian/Ubuntu from scratch on my Armory Online and Armory Offline machines, to the point where I think I finally have a deterministic recipe that works, and I've put it all onto a set of DVDs & CDs & USB drive:

1 - Debian/Ubuntu installer DVD

2 - CD with bitcoin core *.tar file, Armory *.deb file, and a bunch of *.deb files for Armory's dependencies - plus the GPG-verified ASC files

3 - a 64-gig USB drive to hold the already-downloaded blockchain (through repeated wipe-cleans and re-installs of the Armory Online machine) to quickly copy onto the freshly installed Armory Online machine

---

(5) After some confirmations, the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 should now have coins in them - and the "temporary" non-HD wallet should be empty. And no private keys were every exposed on an online machine.

To verify that the HD wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 do indeed contain the coins, would I do the following:

(a) Make "watching-only" versions of existing offline wallets W-HD-FINAL-1, W-HD-FINAL-2, W-HD-FINAL-3 (on the offline machine); and then

(b) copy them to the online machine, and there I could confirm that the addresses have the correct number of coins?

--

Final questions:

(1) Is the above approach correct / sensible / optimal?

(2) What about multi-sig?  Does using multi-sig impact the above steps at all?

Thanks for any help!

Note:

This same question was asked twice here earlier this year, but today is the first time any suggested work-arounds or solutions were provided:

https://bitcointalk.org/index.php?topic=1117735.0

https://bitcointalk.org/index.php?topic=1117735.0

Comment:

We should bear in mind the following two points:

(1) Security is very important to users of Armory - including GPG-verifying the downloaded files.

(2) The Armory program itself is well-designed and has a friendly user interface, even suitable for non-advanced users.

Therefore, it is important to make sure that the instructions on the Armory download page should not have any errors, inconsistencies, non-working links, or outdated information - which could scare off new, non-advanced, security-conscious users who are interested in installing Armory.

Also, the Armory downloads page should include the actual instructions on how to install a downloaded deb file in Ubuntu, eg:

This would help users who how to install Ubuntu but might not know how to install a deb file.

Again, I don't think Armory itself is only for advanced users. It has a simple and easy-to-understand, user-friendly interface.

It would only take about an hour or so to update the Armory website so that it would include up-to-date and complete instructions for installing on various OSes, in order to avoid scaring off new users (who might be willing and able to install Ubuntu - but could get stopped dead in their tracks due to the outdated / incomplete GPG-verification instructions on the Armory website, and the lack of a one-line instruction saying how to install a deb file on Ubuntu).

After all the great work you've done on Armory, it would be pity to alienate potential new users simply due to failure to add a couple of paragraphs to the website.

SOLVED

Reproducing the steps here in case any other users might find this helpful:

How to verify the Armory binary on Linux (in this case, Ubuntu):

(1) Do 'cd' to the directory where the deb file was downloaded.

(2) Do:
(substituting the name of the particular deb file which you downloaded).

This should produce something like the following output:
(3) Look in the file:
and make sure that the hash shown in the above file for the file being checked (in this case, armory_0.93.2_ubuntu-64bit.deb) matches the hash produced in the output for step (2).

(4) Also verify the signature of the file:
by doing:
This should produce the following output:

Hi knightdk, thanks for these suggestions.


Yeah I guess those instructions are wrong now.

This other method you suggest trying, I think that's actually how I did it a few years ago, when I first downloaded a much earlier version of Armory for testing. I think I recall how to do that.

As I recall, it's a two-step process, right?

(1) Verify the signature at end of *.txt.asc file:

https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.93.2_sha256sum.txt.asc

(2) Run some sha256sum program against the downloaded *.deb file:

https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.93.2_ubuntu-64bit.deb

and verify that the hash produced matches the hash for the deb mentioned in the *.txt.asc file.


Thanks, I removed the :11371 from the URL in the browser, and the page displayed correctly.

Perhaps the link on the Armory downloads page:

http://pgp.mit.edu:11371/pks/lookup?search=bitcoinarmory+offline&op=index

should also be modified to:

http://pgp.mit.edu/pks/lookup?search=bitcoinarmory+offline&op=index

so that it would work - to avoid confusing the users.


Yeah, I double-checked the (very similar-looking) version numbers (0.93.2 vs 0.92.3), plus I also enabled Javascript in my Tor browser for the Armory downloads page - and clicking on the 2nd tab doesn't actually display the stuff for the older version (0.92.3).

I recall that the Armory website had some similar problems a few years ago - some Ajax or JavaScript stuff that wasn't working right.

I suspect that whatever web framework was used to develop the Armory website might have some kinks in it.

Comment

I understand that Armory has this reputation for being only for "advanced" users (and in earlier versions it was a resource hog).

But I've installed and tested Armory and found it straightforward to use.

In other words, the Armory software is very user-friendly, and (in my opinion) suitable for all levels of users, not only advanced users.

But in order for non-advanced users, the GPG-verification instructions on the Armory downloads page should probably be reviewed and updated to correct anything that's out-of-date or potentially confusing, and perhaps make the instructions a bit more user-friendly, to accomodate non-advanced users who might want to use Armory.

So: the software itself is very easy to use - for all levels of users, from beginner to advanced.

But the Armory downloads page has outdated and/or incomplete instructions (on how to GPG-verify the binaries), so this is probably a factor which could discourage non-advanced users.

Cleaning up the instructions for GPG-verification on the Armory downloads webpage would probably be a major help to encourage more users to adopt Armory.

Thanks!

Hi GoatPig, I recall seeing your name here a few years back when I previously installed an earlier version of Armory and was testing it out, and I understand you are a dev on the project, thanks for your prompt replies here.


I'm also not familiar with the specifics of dpkg-sig, but it sounds like it's probably a fairly standard debian-based tool for verifying the signatures of *.deb files.

This still leaves the question of why the instructions on the Armory website don't work. I suspect the instructions on the Armory website have gotten out-of-date, with respect to whatever is in the *.deb package for the current release (ie, file '_gpgbuilder' is apparently no longer included in the *.deb ?)


OK, I can try that approach, as I've done it for several other open-source software packages.


I didn't mention, but this is a dedicated Ubuntu 12.04 machine which will only be running Armory Online. The only stuff that's been installed on it is the dependencies for running bitcoin-qt and Armory.

(I also have another machine, identical hardware and OS, which I will be using for Armory Offline.)


I actually have yet another machine, identical hardware, but running Debian 8.0 (Jessye) which I use for my own development. I suppose I could try running the GPG verification stuff there as well.

Still I'm perplexed why the instructions on the site don't work.

I suspect something got out-of-date due to some change in a recent release. From the information mentioned at the stackexchange link from someone with a similar question involving the Offline Bundle for an earlier Armory release...
https://bitcoin.stackexchange.com/questions/35840/verify-offline-bitcoin-bundle-on-ubuntu

...it looks like the (Armory Online) *.deb file from that earlier release included a file '_gpgbuilder' which could be extracted using 'ar vx' and then the GPG verification would work as described in the instructions currently on the Armory download page.

So I think what's going on is that the Armory release changed at some point (to no longer include the file _gpgbuilder in the *.deb file to be extracted using 'ar vx'), but the Armory website download page still contains outdated instructions for GPG-verification, which used to work on earlier releases, but don't work on 0.93.2.

Thanks for the suggestions (building from source; doing GPG-verification on another OS such as Debian) - I'll try both of those. Since they're so different from the current approach, I expect one of them should work. I'll post results here later.

Hi -

I am trying to upgrade to Armory 93.2 on Ubuntu 12.04 64-bit, on an online machine (ie, not using the Offline Bundle), following the instructions here:

https://bitcoinarmory.com/download/

(I prefer to do this manually via a terminal, rather than using the secure upgrade included in the Armory GUI.)

When doing the GPG verification, I run the following command:


This produces only the following output:


- ie, the output does not include the following line, which should have appeared according to the instructions:


Why is this line not appearing? It looks pretty important!

If this line doesn't appear, is there any way of being sure of the integrity of the downloaded *.deb file?

The only reason I am using Armory is because I am paranoid about security, so when this kind of inconsistency happens, it gets me worried.

I will have to delay my plans to start using Armory until a satisfactory explanation is provided of what is going on here.


Transcript:

Here is the full transcript of commands and outputs from my terminal session, running Ubuntu 12.04 (64-bit):



Note (1):

The following link on stackexchange recommended running the 'ar vx' command, which also occurs in the above transcript.

https://bitcoin.stackexchange.com/questions/35840/verify-offline-bitcoin-bundle-on-ubuntu

In the transcript and file listing shown at the above link (involving an older version of Armory), a file '_gpgbuilder' is extracted.

However, in the current version of Armory, no  file '_gpgbuilder' is extracted.

I wonder if this file '_gpgbuilder' is necessary in order for the command 'dpkg-sig --verify *.deb' to work properly?

Note (2):

The download instructions mention that the offline signing key is "Also available on MIT PGP Public Key Server", at the following link:

http://pgp.mit.edu:11371/pks/lookup?search=bitcoinarmory+offline&op=index

This evidently gets translated from http to https when clicked on - ie, it goes here:

https://pgp.mit.edu:11371/pks/lookup?search=bitcoinarmory+offline&op=index

In my brower (Tor 5.0.3 / Mozilla Firefox), it went to a page saying:

   Secure Connection Failed

   An error occurred during a connection to pgp.mit.edu:11371.
   SSL received a record that exceeded the maximum permissible length.
   (Error code: ssl_error_rx_record_too_long)

   The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
   Please contact the website owners to inform them of this problem.

Is this something I should be worried about?

Note (3):

I can't get the tabs to work on the downloads page here:

https://bitcoinarmory.com/download/#tab-pre

https://bitcoinarmory.com/download/#tab-stable

I'm running Tor 5.0.3, and I allowed all scripts on the page.

Note (4):

The wording may be unclear (or the version numbers outdated) in this section:

"Offline bundles for Ubuntu 12.04 have been removed in 0.93.1 due to compatibility issues. Please use the offline bundles posted on the 0.92.3 tab, which is perfectly compatible when paired with an online computer using 0.93.1."

I want to use 0.93.2, so does anything in the above paragraph pertain to me?


Comment:

I assume the issues mentioned above are probably innocuous, perhaps due to instructions on the Armory website not being updated to keep in synch with latest software release, or perhaps due to problems at other websites such as pgp.mit.edu. (If so, is there some other website which can be used as an alternative instead of pgp.mit.edu, or some mirror?)

If I were merely installing some other software where security wasn't paramount, then I would of course ignore these probably minor issues and simply plunge ahead and start using the software.

However, the reason I chose to use Armory is because I want to be absolutely certain about security.

So I will unfortunately not be able to start using Armory if an apparently crucial confirmation message involving GPG fails to appear, or if a website involving GPG can't be displayed due to some problem apparently involving SSL. This is an exercise in security, not in expediency, so when something strange like this happens, it seems like it is imperative to put the installation on hold and report it and await further clarification.

I do understand that the Armory developers probably have much bigger things that they're dealing with - such as the crypto and security involved in the Python and C++ code of the Armory software itself.

But it's important to also make sure the instructions and links on the website are consistent and up-to-date. Otherwise all that great crypto software engineering might go to waste, if users get scared off by these unexpected GPG and SSL messages when trying to verify the integrity of the downloaded files, perhaps due to outdated instructions or bad links on the downloads page.

Thanks for any help!

Hi -

I have some questions about:

- running different versions of Armory on an online machine and an offline machine (when doing cold storage);

- whether the dependencies included in the Ubuntu "offline bundle" for the older Armory 0.90 would still be valid to use in order to do an offline install of the newer Armory 0.91.2; and

- which version might be "better" (i.e. more secure/stable) to use at this time - 0.91.2 or 0.91.99.8 - for someone who just wants to do cold storage plus a little spending?


Questions

(1) Is is possible to use a different version of Armory (and bitcoind) on the offline machine and the online machine?

Or maybe it might be "possible" but still somehow "unadvisable"?

This came up because I recently had to upgrade my online Ubuntu machine to Armory 0.91.2 due to crashes happening in Armory 0.90, possibly related to LevelDB - but my offline Ubuntu machine still has Armory 0.90 because I can't find an "offline bundle" for Armory 0.91.2 .

(2) (If it's impossible or unadvisable to use different versions, then...) Can I use the Armory "offline bundle" provided for the older Armory 0.90 (perhaps by tweaking the install script .sh file?) in order to install the newer Armory 0.91.2 on the offline machine?

In other words, are the dependencies for Armory 0.90 - which are included in the "offline bundle" - the same as the dependencies for Armory 0.91.2 (in particular, the version numbers of the dependencies)?

(3) For just doing cold storage mainly, which version would be more stable / secure to use at this time: 0.91.2 or 0.91.99.8?


Details (basically a rehash of above - ok to skip!)

I have a dedicated online machine and offline machine which I purchased in early 2014 solely for running Armory, where I had installed the following versions:

- Ubuntu 10.04
- Armory 0.90
- bitcoind 0.8.6

Now I'm getting ready to implement cold storage and sweep balances to Armory from an old Win7 bitcoin-qt wallet (originally online a few years ago, later moved "offline" simply by saving multiple copies on CDs and USB sticks and deleting the wallet from the Windows machine).

Now when Armory 0.90 on the online Ubuntu machine finished downloading the blockchain and building and scanning the databases, it started crashing.

I had heard elsewhere about Armory crashing but I thought it had only happened with earlier versions such as 0.88 (due to the need for a lot of memory) or some Mac versions (due to issues with LevelDB on the Mac)... so I was surprised to see it happening with Armory 0.90 on this Ubuntu machine.

I followed the steps recommended in the Armory troubleshooting (I used the Armory Help menu to rebuild the databases, and later deleted the ~/.armory/databases folder) but Armory 0.90 continued to crash, generally a few seconds after launch. I got kinda bummed out because it seemed like I wouldn't be able to use Armory (looked briefly at some other wallets: considered MultiBit but I wanted to avoid Java, and considered Electrum which initially seemed appealing but I didn't like the idea of a server knowing all the addresses in my wallet...)

So I went ahead and upgraded to the following versions on the online machine:

- Ubuntu 12.04
- Armory 0.91.2
- bitcoind 0.9.2.1

This seems to have solved the crashing problems.

To save time, I also restored a backup of the blockchain (I assume it's always compatible), and now Armory 0.91.2 is building and scanning the database, saying it will take a few hours.


(1) Are different versions on different machines ok?

I have only upgraded the online machine to Armory 0.91.2 - because I couldn't find any "offline bundles" at https://bitcoinarmory.com/download for Armory 0.91.2.

So the offline machine still has the older versions:

- Ubuntu 10.04
- Armory 0.90
- bitcoind 0.8.6

I'm concerned there could be problems involving crashes, security or compatibility if the offline machine continues to use these older versions, so I would like to know if there is a way I could upgrade the offline machine to also use Armory 0.91.2.


(2) Are the install script and the .deb's for the older "offline bundle" (0.90) still valid for newer versions?

Could I just use the old "offline bundle" for Armory 0.90 and make some tweaks to the install script so that I can install Armory 0.91.2 or 0.91.99.8 (and bitcoind 0.9.2.1) with the correct dependencies automatically included?

Actually I just looked at the .sh file included in the "online bundle" for Armory 0.90 and it just says:


So I guess my question is:

Are the dependencies (the .deb files?) which are included with the "offline bundle" for Armory 0.90 also usable to do an offline install of Armory 0.91.2 or 0.91.99.8? (In particular, are the versions of the dependencies ok?)


(3) What would be the "best" version to use now for cold storage and some spending?

Finally, I had deliberately installed 0.91.2 since I was unsure whether 0.91.99.8, being relatively new and called a "pre-release" and not mentioned in the ChangeLog, was recommended for use for serious cold storage. Which one would be more stable or secure at this time - 0.91.2 or 0.91.99.8? I don't really need newer features like multisig yet - I just want to move most of my coins from my old (online) Win7 bitcoin-qt wallet to cold storage for safety purposes, and I also want to leave a small amount in a hot wallet because I need to buy some stuff now.


PS - Possible issues on the download page :-)

Also I wanted to mention that the Armory downloads page https://bitcoinarmory.com/download seems to behave differently in different browsers: sometimes certain downloads are missing. This was also mentioned here:

https://bitcointalk.org/index.php?topic=667967.0

This may be happening if something like JavaScript or Ajax is being used to show and hide sections in the table of downloads on the page. In the worst cases (in Chrome on my Win7 machine) no downloads are shown at all.

It might be better to simplify the site so that it just shows a plain list of all the available downloads in everyone's browser.


Thanks to etotheipi and the other developers for their work on this excellent wallet!

rP32R15o4P8nfQSGdZHKoLcTywhaDkKCAc

Actually my timing was all screwed up.

I heard about them during the first run-up to 30 USD in 2011, and wanted to get some.

Got a few via OTC in the IRC, while I was waiting for my dollars to hit dwolla so I could trade on mtgox.

Then I think the crash happened on MtGox. I can't remember all the details, but I ended up buying at around 18 USD.

Then they subsided down to 4 USD or 2 USD, but I had spent all I could on them, so I couldn't get any more.

Just crappy bad luck / bad timing on my part.

But now they are back around 50 and I think they will go much, much higher, so I am excited again.

I think we're going to hit an (arbitrary, psychological) tipping point when the price of 1 BTC equals the price of 1 (troy) ounce of gold - currently around 1,500-1,600 USD.

When that moment comes, I think a certain percentage of people who invest in gold will suddenly "see" that BTC shares many similar useful properties, but BTC has much better "versions" of these properties (eg, you can put multiple copies of your wallet on pendrives, paper, brainwallet; you can take it on a plane or encrypt it and email it to yourself, etc.)

So I envision a certain percentage of gold holders switching some of their holdings to bitcoin.