Raize, you are welcome to donate it to me.  All donations up until this point have gone to me, not the company, though at some point we will transition the address (and mark it clearly on the website) that future donations will support development (i.e. going to paying salaries of everyone working on Armory).  Up until this point, most people thought their donations were going directly to me for what I've done so far, so I made it clear to the investors that until the specified time I will continue to keep them.  Also because CEOs of startups who have the most equity (the most to gain), tend to also have the lowest salaries.  It's part of the risk I get to take given all the potential upside I have.  Until the company actually starts turning a profit, I'll be getting paid below my market value so that we can contribute more money to these superstar developers for whom we have to compete with the rest of the job market.

I'm not complaining -- I'm doing what I love doing and I am still making enough to be comfortable, so I don't have much to complain about   But donations are still appreciated and remind me how much people like the work I've done. 

Take that for what it's worth.

---

Goatpig -

Want to double-down?  I'll make it 3 BTC if you can take your working project and integrate the latest leveldb with it.  I haven't tried it, and as you said it might just be plug-n-play.  In which case this would be the easiest 1 BTC ever.  Or it may take some work.  But in the interest of optimizing my time, it's worth upping the bounty a bit to get you to investigate that for us   You seem to be quite experienced with C++ and MSVS, so you seem like the right person to send headfirst into this one.

We already started BitSafe integration, and plan to do Trezor as well.  Slush has tried contacting me a few times but I've been super busy (for obvious reasons), and figured I'd back to him when I have the resources to execute it.  I also thought I had more time, but it looks like Trezor release is closer than I realized. 

Support will be there.  It's going to be higher priority than the new wallets, actually (because it's very easy to integrate with Armory).  We have a new guy coming in at the end of the month who has the perfect skillset for doing this integration.

Yes, I'm talking about Shamir's Secret Sharing.  I have developed a full interface around it and will be releasing it along with the RAM-reduced version of Armory.

I just want to reiterate my position on this -- I have outlined in the past why I don't want to support directly-encrypted backups.  Not everyone agrees with the reasoning, but I'm sticking to it because the ability to recover your wallet is higher priority than having the extra physical security.

Instead, this is being addressed with the fragmented backups.  It is a perfect mix of redundancy and security, and can be used very similarly to an encrypted backup without the same risks.  Fragmented backups have already been merged into my development branch, and will be part of the next release along with the the RAM reduction.

Armory wallets have not supported compressed keys yet.  They would've by now if I had been able to finish RAM-reduction and gotten around to the new wallet format (that would've supported a lot more exotic things than compressed keys).

To be clear -- I could probably "support" compressed keys "quickly."  They're not complicated and all the pieces I need are waiting in my project for me.  But the wallet code is excessively, thoroughly tested.  That wallet code has hardly been touched in over a year because I'm so careful about making any changes that might compromise the reliability of the algorithms.  I'm concerned about something like getting an address, sending coins to it, and then realizing that it actually sent it to hash(compressed-pub-key-plus-32-bytes-zeros), which would not be spendable.  These are things I have to be extremely conservative about, and while I could implement something that probably works, very quickly, the testing is 80% of the work.

I have to get RAM reduction finished with the fragmented backups.  Then I'm getting married and going on my honeymoon   After that, I'll get a chance to work on the new wallets.

Well there's actually a pre-testing version available for Linux now, that you can technically checkout and use.  It has all the above properties, including 250MB RAM usage and saving scan data between loads.  But importing/sweeping/restoring addresses & wallets is a bit funky.  If you only do those ops while in offline mode, then it will rescan next time it's online, and then shouldn't rescan again until import/sweep/restore more stuff.  So far I've had it running for a week on my dev system, and it's stable.  But those rescan/rebuild ops are giving me more trouble than I was expecting.

Today I'm going to see if I can get it working in Windows.  It will have the same caveats, but at least it will help people move their money if they've been shut out up to this point.  
 
For reference, starting a company is a lot of work!   That's why this has taken me so long -- I've been thoroughly distracted with endless paperwork, negotiations, contract terms, lawyers, recruiting, finances, setting up bank accounts, etc.  I've been able to do some development in between, but obviously not at the rate otherwise.

So yes, I said these thing back in May, but I also hadn't anticipated going through such a grueling investment deal.  But now people can start believing me, because I actually have a version out there they can use

It is a false positive.  guardian.exe is a process that is installed with Armory on Windows. 

And so it begins...

PM me and let me know what you think you can help us with.  By default, we will be trying to do things ourselves with already-paid labor, and that's how we learn anyway.  But if especially if we're bogged down and it's a compact and measurable task we'll consider outsourcing.

We might need help with the Windows build system.  But we also might have figured it out already.  Linux packaging could use some help, but we have a hardc0re linux nerd coming in at the end of the month so I will assume he's got that covered

We actually have some money bookmarked for outside help, like what Red Emerald has done in the past.  If we need something that no one on our team knows how to deal with, we may simply offer them some short-term funding at a reasonable hourly rate to help out.  I don't expect us to be doing a lot of that, but it's definitely a "tool" we're keeping in our back pocket.

Just to address 2112's comments... yes I classify as a "lone wolf" coder when it comes to Armory.  That doesn't mean I have never worked with other people or that other people don't like working with me.  It means that Bitcoin, and especially Armory is a complicated project, and few people have the right mix of skills, motivation, and free time to get involved in a project like this "for free".

At my previous job, I worked on a team of about 6 devs/engineers developing a massive physics simulation, which was in constant integration with the work of 3-4 teams of similar sizes.  The last few of those years, I was in charge of my own little sub-are of the project, with 2-3 coders working both under & parallel to me (I was the task lead while also being a task contributor).  

Starting this company and managing 3-4 developers is basically very similar to what I was doing before.  And real talent is being brought in, and paid well with good benefits to focus on Bitcoin full time.  These are guys that that don't have much knowledge about Bitcoin but are superstar programmers who will have no problem learning about Bitcoin.  If I had to limit myself to super-star Bitcoin programmers, I'd have very little choice -- if they're really good, they're probably already employed by another Bitcoin company.  Plus this has the benefit of bring more talent into the Bitcoin ecosystem, instead of just redistributing it.  I find that awesome developers are literally 5x more valuable than average ones, and I'd rather keep the team small than  fill it with mediocrity.  

Also, I don't think the "recent graduate" comment applies to me anymore.  I worked there for 7 years and had many leadership roles.  "Young" -- yes.  "Recent graduate", no.

By the way, Coindesk just ran the story, after interviewing me.

http://www.coindesk.com/bitcoin-wallet-armory-raises-600k-seed-funding/

"Super-node" is like having blockchain.info on your own computer.  You will be able to query the balance and UTXO list of any address on the network and get an instant answer without any rescanning (it's all maintained on the fly).  And without contacting any servers.  It is ideal for webservers that are doing lots of Bitcoin processing, and necessary for having encrypted watching-only wallets, so that you don't have to do a long rescan every load (otherwise, your wallet may be encrypted, but it's obvious from the database files which addresses are in your wallets).

However, my original implementation suffered from at least one issue related to LevelDB.  I won't claim that my own code was bugless, but the errors were non-deterministic so I determined it wasn't feasible to continue in the short-term (failed with corruption errors on one run, then succeed on the next run using identical inputs). 

For now, I switched to the "regular full-node" implementation like it was before, which requires rescanning on import/sweep/restore of wallets&addresses.  But now it uses the database to save that data between loads, so that you no longer have to rescan on every load.  Still have a bit of internal testing before I can release a testing version, but it's looking very good so far.

Yes, it is redundant, but it the goal is to have Armory become more detached from bitcoin-qt/bitcoind.  There is no way to ultimately connect Armory to a remote Bitcoin-Qt/bitcoind instance unless it maintains its own DB.   Also, these first few versions are maintaining a full database, but the goal to create a lighter-weight version that doesn't duplicate all that data.  But the full implementation is easier, and solves the RAM problem, so it makes a great first step.

Thanks everyone, and you too goatpig!  Your help was actually tremendous.  Just because I have full time people helping doesn't mean that we no longer will need help from the community!  We actually have already tried out your solution and it appears to take us much further than we got before!  So I'm glad you helped, and I think you deserve the 2 BTC.  Though, I just realized that your solution uses a very old version of LevelDB ... I haven't tried merging that project with the latest LevelDB, but we will need to do that eventually.



Check out armoryd.py.  After this next update, armoryd.py will be stable, and you can access everything that Armory GUI can do through python.  It's already setup as an RPC server, but of course it currently uses a lot of RAM, and additionally crashes on each blockfile split (about once a week).  For reference, I even have unit tests for blockfile splits, and they pass... but somehow it still crashes when run on the live network  I've already confirmed the new version doesn't suffer from this problem.  While you can use armoryd.py as an RPC server (a very minimal one), I'd actually recommend using it as a template for just creating your own armoryd.py which is fully customized for your use case.  Now that it will be stable with the next release, I'll spend some effort upgrading it with some more functionality, which will make it more useful both as a server, and as example code for modifying it yourself.

Big news! 

https://bitcointalk.org/index.php?topic=56424.msg671650#msg671650

P.S. - This is still the Armory discussion thread, I just changed the topic temporarily to draw attention to the big news!

@goatpig -- thanks!  you may yet get the bounty.  But I'll be back to you later after the media storm subsides

If anyone has been anxious awaiting "something big" that was it.  Armory just got a huge injection of money, and we're going to start taking Armory -- and Bitcoin -- to the next level   It's a shame I couldn't get the new version of the software out in time, but oh well.  I'll have it soon!

To allay any concerns about "selling out", I want to reassure you all that the reason I picked Trace as my investor (I had a lot of investors approach me) is because his vision is very well-aligned with Armory's.  He is very insistent that money & revenue is irrelevant for the next 6-12 months.  He wants to see Armory get easier to use, multi-sig implemented, Android app, HW wallets, and a server version that can replace bitcoind.  He believes that Bitcoin needs these things more than he needs short-term return on this investment.  This is very cool, because it means that I can focus on developing cool stuff, instead of figuring out how to make money.  Of course, I will eventually have to spend effort on the revenue side, but the top priority for the next 12 months is getting Armory usability expanded for both new users and power users.

Part of it is that Trace and the other investors have a lot of Bitcoin investments, and are really trying to figure out how to get Bitcoin into great adoption/acceptance.  Funding Armory to do this development benefits them even if Armory fails as a business (but succeeds as an open-source project).    For months, he has been saying that wallet apps are the weakest point of the Bitcoin system, and we need more wallet usability, functionality and security.   I'm very excited that Armory will eventually be able to provide all that.

For now, I have a ton of work to do.  But you guys can sleep easy knowing that I'm officially on this full-time!  Thanks for all your guys' support on this.  Armory's reputation doesn't come from nowhere... it takes a userbase to like it enough to talk about it, share it, promote it, etc.  So thanks everything for helping me get to this point.

---

In case you're wondering:  the way you guys interact with me and Armory will not really change,  I plan to remain very active on the forums, and will probably even continue code development on github.  What might change is that I'll have a couple new code wizards joining the team, and will probably be on here answering forum posts and responding to emails.  I'm hoping that once these guys are up to speed, we'll really be able to take off.  For reference, we currently have two other employees in addition to me, and we'll probably be getting a third.  But we're still working out some budget stuff and not sure whether I have time to organize that many brains

I used Blender.  It's a bit overkill, but I like how I can eventually start scripting my design process, and always wanted to learn more 3D design stuff in the future, so I guess I'm one step closer now.

I bought the "MBot Cube 2" printer.  It is basically a cheap Chinese version of the Replicator2, and I've had quite a few problems getting it working.  But once I got the new printer head that handles PLA, it's been pretty smooth.  It actually prints beautifully once you get it working!

You missed the part where I'm not talking about cracking a password from scratch.  Part of this process is that the user describes everything they know about their password, to reduce the search space from 5,231,234 possible passwords, to 2,381.  It may still be too much for one person to find it, but small enough that it could be done in a couple weeks by 10 people who all want the finder's fee.

If you look at the proposal again, you'll see that the original key-stretching is still intact.  All the brute-forcers still have to guess through the KDF (or try brute forcing the 256-bit encryption key directly, if they're dumb).  It's just that they're using info from the original user to reduce the search space to something feasible.

About 1-3 times per month I get emails from users in exactly this situation.  They give me as much information as they know about what the password might be, and I either tell them (1) you don't know enough to make this feasible, or (2) Here's a script that tests the most likely 2,381 passwords against your wallet, it will take about three weeks to run.

P.S. - For reference, the default settings for an encrypted wallet in Armory, requires 0.125-0.25 seconds of compute time, with somewhere between 1 and 32 MB of RAM usage.  Therefore, when I user gives me their wallet, I can usually process about 5 passwords per second per core.  With my quad-core system, that's 20 passwords per second.  So I can do somewhere between 1M and 2M passwords per day if they give me their wallet and it was created with default settings.  Of course, I've gotten users in the past who set compute time to 5 sec for "extra security", which turned out to be extra security from themselves...

The next version has solved all of these problems (currently in the ramreduceleveldb and rrld_planB branches).  It's not quite ready for testing, but should be very soon.  Armory now builds the database and scans it on the first load only, saving everything between loads.  And only uses like 250 MB of RAM (which should be independent of the blockchain size). 

Obviously, this is a huge step up from where it currently is.  I just haven't had the time to overhaul the relevant code until now.

This doesn't weaken the KDF at all.  Unless your passphrase is 256+ bits, in which case it's secure, regardless.   ("Note that you don't lose the benefits of key-stretching because the SHA256^1,000(passphrase) has the full 256-bits of entropy.  It's still quicker to brute-force the lower-entropy passphrase hashing 1,000 times on each guess, than brute-force the 256-bit key without any stretching.").


That is true about the race, but it seems that you've solved it with the precomputed refund.  Once he's got the payment tx, he can personally give you the password knowing that he can redeem it.  That way you can unlock and sweep before he broadcasts the finder's fee tx.  Worst case, he broadcasts with the key and you get it from the blockchain, but that would be a last resort.  Does that work?