Non-US Users.  Please help me test!  Need unicode/non-en-us users to try it.

Armory 0.87.97-testing!  All testing releases are signed!

The new auto-bitcoind stuff came with a host of critical unicode issues.  In the past, such issues were simply annoying, but didn't actually prevent users from using Armory.  Now it did.  I have upgraded the critical paths to handle unicode, and added warnings for everything else.   One exception to unicode handling is that you cannot use unicode in your bitcoin.conf username or password, and only in Windows!  (it works fine in Linux)  Otherwise, I'm hoping this will go a lot better than before!

See the call for testing help:  
https://bitcointalk.org/index.php?topic=156250.msg1655941#msg1655941

Improvements from 0.87.95:

-Unicode issues addressed
-New offline bundle for Ubuntu 64-bit
-Frag/unfrag scripts bundled properly now in the offline bundle, I think
-Fixed a problem with existing, partial bitcoin.conf files.

Non-US Users.  Please help me test!  Need unicode/non-en-us users to try it.

The new auto-bitcoind stuff came with a host of critical unicode issues.  In the past, such issues were simply annoying, but didn't actually prevent users from using Armory.  Now it did.  I have upgraded the critical paths to handle unicode, and added warnings for everything else.   One exception to unicode handling is that you cannot use unicode in your bitcoin.conf username or password, and only in Windows!  (it works fine in Linux)  Otherwise, I'm hoping this will go a lot better than before!

See the top post for details!
https://bitcointalk.org/index.php?topic=156250.msg1655941#msg1655941

Just think of your offline computer as the "check signer".  He can read the check, and will sign the check if you tell him to.  But you should make sure the check says what you think it says before you sign it

Additionally, Armory uses BIP 10 to communicate transactions with the offline computer for signing.  It guarantees that if offline Armory says "Do you want to sign this tx sending X BTC to address Y with fee Z", you can be sure that the transaction really is sending X BTC, to address Y, with fee Z.  You just have to actually check it on the offline computer, instead of loading it and blindly hitting "Sign".

Just like in 2011, I'm pretty certain the this event is just the system reverting to mean.  I don't know what the mean is, but it wouldn't surprise me if $266/BTC was $100 real-value + $166 speculator-mania.  If you look at the 2011 bubble, there was actually a fairly smooth growth curve that persisted, underneath the 1,000% bubble.  I'm expecting to see the same thing happen here, but with a "higher" mean, because there was actually a lot of real growth of Bitcoin, underneath the speculation.   I just don't think the real growth reached $250/BTC yet. 

Indeed.  I have suspected for a while that the run-up was a bubble, though I expected it to persist a bit longer.  All this media attention came in only last week, and thought there was going to be another couple weeks of people pouring into the system.  Maybe there still will be.  But I'm not afraid of the price "reverting to the mean", only the ensuing media attention which going to cast it into a poor light.  And it's partly justified -- people are going mental, and panicking, and our poor little infrastructure can't handle it!

For reference... 2 months ago I was at about 2,000 downloads/month.  Now I've gotten 2,000 downloads in the last 2-4 days!  I'm also getting a lot more emails and postings about it.  Obvioulsy no one else can respond to the emails, but I request some help responding to postings in the Armory subforum.  I'm going to try to resist the urge to respond to these things immediately, and give others a chance to help me, first.  I'm going to focus on coding

Can you please call my bank and convince them to let me pay off my mortgage in Bitcoins? 
(I say that as a joke, but I just realized it's theoretically possible you could make that happen)

Sure BTC is great.  But most of life revolves around fiat -- especially debts that were issued in fiat.  And who the hell wants to take a debt out in BTC when it could go up 20x by next year and they'll be declaring bankruptcy?  I believe there will be a point in time in which BTC stabilizes, and probably at a value much higher than it is now.  But it's going to be turbulent, and probably a long time before BTC can truly act as a replacement for fiat.  Until then, some of us would like to diversify -- BTC, USD, Gold, Real estate, etc.  That requires cashing some out...

Update,

(1) 0.87.9X hasn't gone so smoothly.  It looks like most of the problems are unicode-related (and one bitcoin.conf file problem).  I was planning to fully upgrade Armory to be unicode-friendly with the new wallets, and most people can avoid using unicode in most fields until then... except with this new version.  I have to get some unicode fixes in there, as there's quite a few people who aren't able to use the new version without it!  Hopefully that will resolve a bunch of the problems I've been observing in testing.

(2) I released a signed, 0.87.95 offline bundle, which works for Armory GUI, but not the frag-unfrag scripts.  I included them, but it turns out I made a git merge error and they don't work!  However, I merged things into testing, which includes this, and I'l re-release the offline bundle along with the unicode fixes.

P.S. -- Geezuz, what a day on Gox! 

Not without taking a screenshot.  Though I was close to figuring out how to put images on the clipboard, but I never quite got it to work.

On the other hand, screenshots aren't so bad.  Both windows and linux, you should be able to <alt>-printscrn or <ctrl>-printscrn and it will put the window in focus on your clipboard which you can then copy into another application.

The OSD keyboard can be defeated.  But simple, off-the-shelf pluggable keyloggers, only record keystrokes.  This isn't intended to be a replacement for real security, it just raises the bar a tad for what an attacker needs to attack you.

Well, the next release of Armory will have some help on the keylogger front (see images below).  The keylogger would have to record mouse-clicks in order to get your passphrase, and even that is useless if you scramble the keyboard.  Anything advanced enough to break that, will get your private keys another way.

As for the USB viruses:  that is a very real, and very remote threat.  It's not to say it couldn't be done.  It's why I've got the Improving offline wallets thread.  The reason why I stick with USB is so that people use it.  I'd much rather they use USB keys, than get fed up with something complicated, or not supported on all OS (battling drivers issues), and then resort to just regular hot wallets.  USB keys are universal, and everyone understands them.  No doubt, though, I'm working on some alternatives, for advanced users.

I'm not sure I see the difference.  I'm using a 80-character alphabet of "symbols" to represent my password (they just happen to be the same symbols I have on my keyboard).  And I'm displaying those symbols on the screen.  The downside is those symbols are chosen by the user, and have this "shift" key artifact that reduces entropy if someone measures the shift key presses.  And if they have lots of duplicate characters.

But those "weaknesses" are solved by the dynamic keyboard.  I think the only difference is what it "looks" like.  And in the end, using my way (dynamically-changing keyboard), the person still has the option to type it in if they don't really care.

Actually, this is a poor-man's Shamir's Secret Sharing scheme, and it's not a bad one, though you can only 2-of-2 out of it.  Encrypt your backup with a really long passphrase on one sheet of paper.  Write the passphrase on another sheet of paper.  Now you need both to recover your wallet.  But if you lose one, you're screwed. 

Actually, you could encrypte multiple times, and get M-of-M out of it (3-of-3, 4-of-4, etc). 

But the beauty of Shamir's Secret Sharing is that you can have, say, 3-of-5 backups -- print off 5 sheets of paper, and any subset of 3 is sufficient to recover your wallet.  As I linked, it exists for Armory wallets, but only if you're comfortable with the command line.  It will eventually be merged into the GUI... it's just going to take some work to unify all the backup options into an intuitive "Backup Center".

But the experience of this "electrician" is that, by far, the most vulnerable part of holding Bitcoins is losing your passphrase, your hard-drive, or online/virtual attacks (like the recent Skype malware).  Not physical security.  Most people are capable of physically securing a sheet of paper -- SSS will simply improve that.

Thanks!  I hope you can get Armory to work for you!  It's still got some usability curve (and some resource requirements), but it works quite nicely when it works   And the resource requirements will be lowered in the next few weeks as I make some major upgrades to the blockchain engine.

I know there's some demand for LTC, but I just can't do it.  But I think someone else could pretty easily, and those changes would merge easily with future Armory updates that I make.  For now, I'm focused on a variety of usability improvements, as well as new wallets with multi-sig, android-support, etc.  Any LTC support will have to be parallel.  You could always post a bounty

I'm working on using Shamir's Secret Sharing as an alternative to encrypted backups.  It's actually implemented and usable from the command-line right now, but not implemented in the GUI.  You can PM me for more details if you want it.


See the end of my previous message.

All this talk about "change addresses" is dangerous.  If you don't understand change addresses, you shouldn't be doing anything like this manually.  It'd be like someone without an education trying to rewire their fuse-box.  I'm sure if you spend some time reading up how to do it, you might get it right -- but also might electricute yourself and/or burn your house down.

In this case, I am the electrician.  I wrote Armory to do exactly what is being requested in this thread.  It's used by thousands of people, and has been for more than a year.  I have figured out all the gory details and put in endless error catching, corner cases, etc, and it's been thoroughly tested.  I wrapped it up in a nice GUI that a non-technical user can use safely.  

-- Backup your wallet one time.  Ever.  Period.  Forget about change addresses, it's all backed up with your paper backup.  Print it or copy it by hand.  A digital backup kinda works, but it is encrypted which doesn't help you if you forget your passphrase.  You laugh, but this is by far the most common reason people lose coins -- not theft or hard drive loss.  Plus digital backups get corrupted.  There's no guarantee it will work when you need it 10 years from now.
-- You create the wallet on the offline computer, and "Create a watching-only wallet" and import it on the online computer.  That wallet behaves exactly like a regular wallet, but without the ability to spend.  You can generate and distribute trillions of addresses if you want, and see payments come in exactly as if you had the full wallet on your system... but it actually has no private keys.
-- To send money, create a transaction like you would with a regular wallet, and the "Send" button will instead say "Create Unsigned Transaction".  Save it to a USB key, take it to the offline computer, hit "Sign", then bring it back to the online computer and hit "Broadcast".  

There's a tutorial here, which will soon be updated with illustrations and screenshots.  Though, most people can figure it out from the in-app hints and that webpage (or from the app, by itself).  If you're really starting from scratch, start at the quick start guide.



There is no LTC version of Armory, but I imagine it wouldn't be too hard for a bitcoin-knowledgeable dev to implement.  I can answer questions about it, but I don't have time to actually do it myself.  You'd probably have to change some constants near the top of armoryengine.py and modify the C++ utilities to use scrypt instead of double-sha256 for the blockheaders.  

I don't think that works.  It needs to reference relative paths to the virtualenv-included python dependencies. 

I have no idea where to go from here.  I was hoping higuys would respond and help... more.  Maybe someone with a fresh OSX install can follow the higuys directions and figure out how to modify it.  I suspect that somehow he was able to create .app with extra stuff installed on his system than comes with OSX. 

To anyone willing to try, I guess I'll offer an extra 0.5 BTC bounty.

(1) Create a fresh OSX VM or installation so that there are no pre-installed dependencies.
(2) Follow Red Emerald's brew instructions (use Method 2).  It will involve installing Xcode and the command-line utilities.  And running python with the PYTHONPATH=... prefix.
(2a) Before you make the project, do a "git checkout osx_managesat", which has the updated Makefile and deploy.sh from higuys. 
(3) You should be able to just "make osx" from there.  But you can also look at what he changed/added in his pull request.

I'm very frustrated.  I've been tinkering for a while.  Not sure what's wrong.  By they way, I'm using OSX 10.8.2

By the way, I just merged the managesatoshi branch, along with the frag/unfrag scripts into the testing branch.  This is a much better place to have people test it!

I think I'm going to try to get a Troubleshooting page up before release, and link to it in the program.  In all the testing so far, a couple problems keep popping up over and over.  Especially the corrupted database issue (which, it turns out, is caused by incompatible versions of BDB ... mostly a Linux problem using the PPA). 

Also, I found out that there is an option when running bitcoind, "-dbcache=<X, in MB>" where X is how much extra RAM you want to allocate for blockchain processing.  Increasing this value speeds up that initial download quite considerably.  I was already detecting system RAM, so I put in a condition to allocate an extra GB if you have 5+ GB of RAM, or 2GB if you have 10+ GB.   On my system, that initial download is probably twice as fast with the 2GB option.

Oh, well for that the scrambled keyboard would seem to be the best solution, since it works with existing password systems.  The symbols technique would require creating a new password-based system... or at least new interfaces to create it.  

I guess the metric to use would be how much extra data does a really smart keylogger have to collect to circumvent this?  Screenshots after every keypress?  At this point, it's no longer a keylogger and just a virus, which if it's this smart, it can just wait until your wallet is unlocked and extract the encryption key from RAM  

PS - Note that if you use the "dynamic" keyboard, the {shift} key is scrambled with everything else, and the keys re-randomize with every key press.  If you use the simple scrambled keyboard (which is randomized once), then something that records mouse click locations gets:

(1) Pressing the shift key is not obscured, so you lose one bit per character to the keylogger, which can now see "UULULLLU" where "U" is uppercase/shifted, "L" is lowercase/unshifted.   This is likely not enough to brute-force your passphrase, but it's still information leakage, and might make the difference between a weak-but-prohibitive passphrase, and one that is worth brute-forcing.
(2) If you have repeated letters in the passphrase, you further lose a little information with the simple keyboard.  i.e. if your passphrase is "9999999", then the recorder sees that your password is 7 instances of the same character.  

For the dynamic keyboard, repeated letters and shift presses, all look like different letters, to anything recording mouse-click locations.  It's optimal "scrambling", though I truly believe that anything in place that could exploit the simple keyboard, has enough to take your coins, anyway.

Presumably, what you suggested would provide similar benefits as the dynamic keyboard gives you, which is producing a "code" which doesn't have repeated characters and which does not have the equivalent of "shift" presses.  My point is that the dynamic keyboard achieves that for you.

What do you mean?  It's one page back:  https://bitcointalk.org/index.php?topic=56424.msg1761230#msg1761230

As for your idea:  I think there's some good ideas out there, but I think they're not much benefit over the existing version.  Yes, you can make it harder it for someone to share their passphrase if you use symbols, or textures, etc.  But I don't think it's worth the effort.  With my limited time, I have to pick and choose my battles wisely, and I don't think that one is one I want to battle