Quote from: mav on January 11, 2013, 09:51:24 AM

The changes to add auth are in the link below. Manually tested only. Returns the string "Unauthorized" if the user is unauthorized (no username or wrong password), otherwise returns the desired json. Credit must go to the author of txjsonrpc for including a nice wrapper for auth.

https://github.com/thedawnrider/BitcoinArmory-Daemon/commit/32cfd4697fed5546c57f5815b15a37f79988db74
...

@mav

You're amazing! You made that look so easy... I guess you just have experience with this to realize that I didn't need all that extra garbage to do something so simple. Thanks so much -- now I can get around to actually implementing all the RPC commands. Ideas are welcome for how to deal with it for things that aren't the same for bitcoind and Armory: for instance, bitcoind has accounts, Armory has wallets. I was thinking it could be a multi-wallet interface, instead of accounts and you give it the wallet ID where you would otherwise put an "account" in the JSON interface. Mapping other functionality over for watch-only wallets may be kind of fuzzy. There's also things where Armory can provide a bit more than bitcoind could -- for instance, the ability to sweep or import private keys could be added (I'm thinking I could have that happen in another thread so that it wouldn't have to go offline... [wait, I could do that in Armory GUI, too... ...?]).

Quote from: Ploo on January 11, 2013, 07:41:23 PM

I'm looking to generate a raw plain hex signed tx that's ready to push later via blockchain/pushtx or bitcoind/sendrawtx.

I've noticed that copy raw tx returns the same value pre and post signing, which i presume to be the unsigned data. Is this a bug?

@Ploo
Yes! I actually was just messing with something and found this bug and fixed it. I don't know if I fixed it in the testing branch yet, but I'll definitely try to get it in, soon. I was annoyed, myself, that I couldn't get the raw tx out of it...

Quote from: wachtwoord on January 11, 2013, 01:39:41 PM

1) Do you agree this configuration is equally secure as a configuration in which a dedicated offline system?
2) The biggest risk here (but also in the proposed configuration with the dedicated offline system) is keeping the offline wallet files physically secure. Especially as you will want to keep backups (flash storage is frail). Do you agree?
3) Why do you recommend making a paper backup? Personally I really do not trust paper (it decays even faster than any other sort of media). I would like to hear your thoughts because you have obviously put more thought into this than I.
4) Finally, atm I already use Armory (although not yet for the majority of my funds) in a configuration with 1 (hot) wallet on a system connected to the internet. I have encrypted the wallet with a very long pass-phrase (>50 characters to give an indication). Will using a offline configuration with a real and watch only wallet really improve my security? What exact use cases do I protect myself against?

@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.

Quote from: picobit on January 11, 2013, 07:25:19 PM

Another possibility would be to have the offline wallet in a virtual machine without internet access. Of course a virus could still get access to the file in which the virtual machine harddisk is placed, and thus the "offline" wallet, but the virus would more or less need to be tailored to attack your personal configuration. So if you keep thousands of bitcoins, you definitely want a dedicated offline machine, but for anything less I would guess that the virtual machine - or even the setup you suggested above - would for all practical purposes be secure.

@picobit
This is probably strictly better than just having an encrypted hot wallet, since it definitely much more complicated to automatically find data in a VM. It's not as good as an offline solution, but I bet a lot of viruses sit around scanning directories looking for wallets, and it would have to be kind of advanced to be able to pick apart the VM filesystem and/or memory space. It's definitely doable, but probably not deterministic (especially if you use some obscure OS in your VM).
(EDIT: though, I'd still place this at substantially less-secure than a real offline solution)