There's a lot of system libraries that Armory depends on.  I can't statically compile all of them.  At least, all these libraries are in the standard repos which are generally widely used, and downloaded with authentication by the package manager.

Also, I don't want a 200 MB git repo by including all these libraries, especially OS-specific ones.  I included crypto++ due to similar problems as this one, but that was a nice compact C++ library.  Maybe I can get the same from python-dev?  I never actually looked at how much source code it is or how much of a pain it is to compile (in all OS)

It doesn't change the fact that my makefile is crappy.  But at least 98% of the problems would go away.  Hmm...

Want to make 0.5 BTC?  It's gotta be much less complicated than I'm making it.

https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/Makefile

I mentioned it a few posts up:  the issue is python-dev.  I need it static-compiled into the project, but I need it to autodetect the location of it, and switch to the .so if the .a does not exist.   I know that Makefile is terrible -- I don't do Makefiles or bash scripting... I did whatever I could to make it work, but it's clearly not very portable...

The subset of features used in offline mode are rarely updated.  I change some of the flow (try to remove unnecessary question boxes), and add a couple convenience features, but nothing you need.  There won't be a "required" update of the offline computer until the new wallet format is implemented, but that may actually still work fine with old wallets -- only needed for new wallets.

I am in total agreement with Gavin about this.  For anything substantial, bounties are a really terrible way to get work done.  However, I have actually had great success with bounties for things like this, which are

(1) Extremely well-defined
(2) A trivial amount of effort for someone knowledgeable (1-3 days)
(3) I'm the only one offering the bounty and I decide (not by consensus) who gets it, and I'm not a stickler about it.

For anything that is more than a couple day's work and without well-defined exit criteria, bounties are a terrible way to go.   Especially when it's a long project and project direction could change mid-way, etc.  In this case, it's clear what needs to happen, and if I end up with something that's not exactly right, I'll still pay the 0.5 BTC.

I should start a bounty to have someone with real Makefile experience rework that Makefile.  I know it sucks.  It works on Ubuntu 12.10-, and requires only small deviations for other OS, but I don't know how to do it "right". 

The only issue appears to be python-dev.  In Ubuntu 13.04, the files end up somewhere unexpected.  In other OS, the static library is not available.  But I need it to compile the static library when available, for distribution purposes (or else it fails to start on many systems when installed from my .deb).  If it doesn't do that by default, I'll inevitably create non-working .deb packages and go through the whole release process not realizing I did it.

So, anyone want 0.5 BTC?  This can't possibly take a long time to do, it just needs someone who has any experience with Makefiles.  If the python-dev library is already installed, it should (1) Try to compile using the static library (.a), (2) If the static library is not available, just use the dynamic (.so) library, and (3) Do so in the "correct" manner to find these things, not hardcoding paths as I have basically done.

Even ink will stain the paper well enough that your'e almost guaranteed to be able to recover it.   You might not be able to identify it by eye, but someone with some tools will be able to read it.  And you only need to do it once to get your coins back.

As for 451 F -- yeah, I just meant "close to fire" but not directly set on fire.  Like if you keep your Paper/USB in a metal box that comes in contact with fire when the house burns down, the paper still has a good chance to survive.  I'm pretty sure most USB keys and CDs would start to melt and electronics overheat ,etc.

It's not an exact science, I'm just trying to dispel the myth that paper is somehow inferior to other options.  I think it's a great option, and easily "upgradeable" to a better option (like putting it in something fire proof).

Unfortunately, it's very likely.  Malware doesn't just get onto your system and leave.  It sits there and does its things.  One of those things could be checking for wallet files periodically.  Or maybe whenever any Bitcoin software is started.   Just because the wallet isn't there when the first malware was acquired, doesn't mean that it will just leave in frustration and never come back again.  It's very easy for it to look for wallet files every time removable media is inserted, etc.

And that doesn't take into account the fact that the malware may not even be looking for wallet files, because they're encrypted anyway and it can't do anything with it.  It just waits for you to open Armory and unlock your wallet, then it pulls your private keys out of RAM (or pulls your passphrase out of RAM and takes your wallet file with it).  In this case, it doesn't matter whether your wallet isn't on the filesystem 99.9% of the time, because the malware doesn't do anything until it detects Bitcoin activity.

The hardware wallets (that don't exist yet), offer superior advantage over a flash drive, because they require a physical keypress, and do not allow download of private wallet data.  The signing is done on the device and it only emits signatures, not private keys.  The attacker can steal the passphrase, but they can't press the buttons on the device to get it to sign things.

And you assume your USB device will work in a couple years.  It might.  It probably will.  But why even take that chance when paper works 100% of the time.  Just about anything that destroys paper will also break your USB key (direct fire, shredding, etc).  At least the paper will survive through water, heating below 451 F, and mass bending/stretching/tearing/deformation.

The downsides of unencrypted paper are mostly resolved by the M-of-N stuff I'm going to be releasing soon.  Though, the backup system will allow you to save some fragments on paper, some on removeable media.  However you prefer it.

Bitcoin is a consensus-building network.  There cannot be a reliable zero-confirmation system using the Bitcoin network alone, because it can't build consensus that quickly.  The whole point of it is that your confidence in the transaction can grow exponentially as a function of work done (#confirmations), but if it has zero work then there is no confidence in it.  At the end of the day, it's that simple -- you can't be confident until your transaction is buried in proof-of-work, which means it must have confirmations. 

That's not to say that there will never be hope for zero-confirmation transactions:  it just means that they will never be (and never were) suitable for zero-trust exchanges without external services.  There are some cool things you can do with locktime and alternate sighash codes, but they all build off already-confirmed transactions -- they require seeding a contract with an already-confirmed tx!   Third-parties may provide mechanisms to help people transaction instantly, and they may take a fee for it.  But you won't get there with the network rules alone.

We need to get away from this wishful thinking that we can somehow adapt this proof-of-work system to work with transactions that have no proof-of-work.  There's still use for them, just not zero-trust transactions (i.e. if my coworker sends me money to cover the lunch tab, I can be confident with the zero-conf, because I can go to his cubicle and punch him later if he double spends, etc -- this is not a zero-trust situation.).   

Obviously multi-hour starting is not supposed to happen.  It's a couple minutes if you have the RAM, and will be very fast/instantaneous after the next upgrade.

Electrum is obviously designed to be fast and easy to get into.  But you're sacrificing privacy, and a little bit of security, by connecting to these centralized servers.  These servers know exactly how much you have in your wallet and all the transactions you execute.  Similarly, any kind of attack that works on isolating a node, works on Electrum.

For a casual user, it's not all that important.  For someone with a lot of BTC, the privacy implications are concerning, and the security issues are not terrible, but they'd prefer to just remove all doubt.

Armory also just has more/better features than anything else.  It's the cadillac of desktop wallets.  If you have the system resources and yo uget it running, it'll treat you better than anything else, you support the network by running a full node, and you've optimized your security and privacy by going through a full node you control, instead of trusting others.

Right now, Armory is really suffering in the usability dept.  I hope that's resolved in the next couple weeks and then people won't have to ask that question again!  (well, it will still require the same effort as Bitcoin-Qt, but not much worse than that).

Do you have any non-ASCII characters in your username?  Like an "é"?  That became a problem in 0.88. 

If so, you might have to stick with 0.87.2 but switch to 64-bit version.  The 32-bit version has stopped working until the next release (with revamped engine). 
http://bitcoinarmory.googlecode.com/files/armory_0.87.2-testing_win64.msi


If you don't have any non-ASCII characters, your problem may simply be that you need to completely uninstall the previous version before installing the new version.  Try that first, then go back to 0.87.2 (64-bit) if it still doesn't work.  In all cases, you're going to have to uninstall the old version, and your wallets will be completely safe through the reinstallation cycle.

If you think about it, just about anything that destroys paper, also destroys digital media.

Water:  paper will survive (it doesn't have to look pretty to be useful).   USB keys might survive, if you let them dry out 100%.  CDs will survive.
Direct fire: are goners
High heat (below 451 deg F):  Paper survives, CDs and USB keys probably won't
Bending & Stress:  Paper wins.  Clearly.
Shredding: paper at least has a chance here.  Good luck reconstructing a shredded USB/CD.

I'm curious what scenarios lead to a destroyed paper backup, but not USB/CD.   Or what would be a reasonably-inexpensive medium that could replace all this that would be more resistent to things.  Though, I think my point was that paper is far and away excellent without needing to search for other options.

Yeah, that's something that I'll actually add to the new wallets when I get back to them... some kind of "schedule" entry that could be used to trigger notifications for making payments.  It wouldn't even just notify you, it would actually pop up with the "Send Bitcoins" dialog already pre-filled in, you just have to hit "Send" (or "Create Unsigned Transaction", if it's a watching-only wallet).

But as you noted, that's low priority.  But I've made a note to myself to add it to the new wallets (though, they are being made with extensibility in mind, so that it should be easy to upgrade later if I forget).

I had considered removing case and making it longer, but I really wanted it to be shorter to avoid having it significantly increase the amount of data to write/type.  I already think it's too long, but I need to make sure it has some kind of sanity check, and enough entropy to be useful. 

On that note: at the moment, it's 7 bytes plus a 1-byte checksum displayed in base58.  That is 56 bits of entropy, drowned in 16MB of key-stretching.   56-bits doesn't sound like a lot, but the keystretching takes my i5-2500K about 0.25seconds to compute.  If you had just a single CPU working on that, it would take 580 million years to go through the possible keyspace.  Even with a multi-million-CPU botnet, you're out of luck.  And GPUs won't be very useful with the 16MB required per thread. 

I figured the case-sensitivity was okay, because I'm displaying it in such a huge font, it's obvious what is upper and lower case.   It can still be changed, though...

I am a vim maniac!  I am always jumping between about 12 vim sessions, and do 100% of my coding with it.  I'm in for 3 BTC!

That kind of 2-factor auth requires a centralized server. Anything that I implement using, say, google-auth, would be purely security theatre.  It would add 2-factor auth for you using Armory, but someone who steals your wallet file wouldn't need it.  It's because the network doesn't care about google-auth.

However, if I ever get back to the new wallets, I will be implementing two-factor auth using multi-sig network scripts.   Then your phone would also have a bitcoin wallet, and the network would expect to see a signature from both.

I absolutely will be doing this, at some point, but I have a lot of priorities.  Not to mention, I need an Android app .  I have someone helping with Android stuff, but it's still a ways off.  This is exactly what you want.

Yeah, but I don't know how many people would ever figure out how to use that feature.  There would be some, but it would be an underwhelming minority

However, the new auto-bitcoind feature has Armory connecting via RPC, so the sendrawtransaction command will fix this problem.  Bitcoin-Qt/bitcoind will broadcast the tx regardless of what it personally thinks about it.

Yeah, the logic has been in the code for a while, and I had all these great ideas for wrapping a GUI around it, but no time to do it.  The conference was the perfect excuse to get it done.   We want to showcase the advanced security features of Armory to people going by.  Of course, we have to warn them "This beta only works if you are on a 64-bit OS with 5+ GB of RAM".  Still, it should whet their appetite and give them the impression that Armory is the Cadillac of Bitcoin wallets.  Then when the resource issues are resolved, they'll be excited they can finally use it

I made a lot of progress on the persistent blockchain stuff, but when I realized I couldn't finish it before the conference, I decided I had to finish this feature instead.  I may not have mentioned it here, but a friend paid for an exhibitor booth at the conference, and he and his buddy are running (and I'll be there, too).  And we got a good location, too, by the door.  We'll be doing lots of demos.  I decided having the super-backup system (at least in demo) was worth delaying the persistent blockchain stuff by a week.

I made a lot of good progress on the persistent blockchain stuff, but it'll probably still be a couple weeks after the conference before it's ready.


(1) The encryption uses the same key-stretching as is used for wallet encryption which is a simpler (but less flexible) version of scrypt.  It's hardcoded to use 16 MB of RAM per thread, which means it must do 262,144 SHA512 invocations, and keep each step in RAM as a lookup table to use for 144k lookup operations.    This will take older computers a second or two, but it will be done so infrequently, I decided, I should err on the side of taking too long. 

(2) There is no custom passphrase.  However, the intention of M-of-N was to replace that.  An encrypted backup is just a 2-of-2 backup -- requiring the paper, and the password in your head.  You can, instead, do a 2-of-2 backup with the new utility, and think of one sheet being the encryption key for the other.  But with this, you get an extremely flexible tradeoff of security and redundancy.  M is how much "security" you want, and N is how much redundancy you want (well, N-M).   

I've ranted before about the dangers of having an encrypted paper backup option, because it's the one place where users should not always pick the "best-sounding" option .. i.e. "Oh yeah, encrypt everything, great!".   I have seen probably 200+ BTC lost to forgotten passphrases.  It's tough to have the encrypted backup option while still encouraging people to have at least one unencrypted backup, somewhere.  Or rather, prevent people from unwittingly creating brainwallets.

Some bounty-goodness, here:

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

Yes, I finally got around to implementing this M-of-N backup stuff.  And it turned out pretty awesome (besides needing some polishing).  

The testing will be useful in general, but I especially need it in the next 24 hours so I can demo it at the conference.

By the way, teaser shots of the new features, if you can't actually get in to use the testing version...