---

Armory Version 0.79.99 -- Initial Testing release

---

I didn't have time to compile for all architectures -- but I got 64-bit windows and 64-bit-Linux compiled (with an attempt at static compiling python, so it may actually work on any 64-bit linux...)  I have tested most of the features in both Windows and Linux, and there's no hint of a problem with anything.  This is mainly due to the fact that everything I changed in the C++ code was transparent to the UI-layer:  I hardly had to change any python code to get it to work!  This is very satisfying.

---

Windows 64-bit installer:
   Load Time:  Slower!  My VM is loading in 80 seconds.  Yes, that is unacceptable, and will be adding between-load memory so it only does it the first time.
   RAM Usage:  700 MB -- this time that RAM usage is a hard-number:  it's not going to scale with programs opening and closing.  On the upside, it should be no more than 200 MB, and I just have to find out where I'm allocating memory and not cleaning it up (luckily, there does not appear to be a time-dependent memory leak).

---

Linux 64-bit installer: armory_0.79.99-python2.6-1_amd64.deb:
   Load Time:  About the same -- my desktop is loading in about 25 seconds.  
   RAM Usage:  700 MB -- see above

---

Some other comments about what to expect:

(1) There's no reason this won't work in Windows 32-bit, I just have to get it compiling and built, there.

(2)  This version isn't going to look a lot different.  In fact, it's not supposed to.  But it's got entirely new architecture under-the-hood for blockchain scanning, which I have actually tested and maintains consistent data through a blockchain-file-split.  Previous versions will stop working when that happens... in about 2 weeks.

(3) If you are on 64-bit linux and normally use the python2.7 version, please try installing and running this version using the
The static compiling went way too smoothly, which suggests maybe I didn't actually do it right...  Please let me know if it works!

(4) I think that the unconfirmed balances are fixed.  They definitely had an error before (counting change-to-self as unconfirmed).

A few minor tweaks here and there, but it should work the same at 0.77.

Please help test!  Testing really just means, install it and use it like you would the previous version, and let me know if there's any strange/undersirable behavior, and/or any crashes!

I actually really like the electrum-way for making seeds memorable.  It's a really slick technique.  But the current wallet design in Armory requires 512 bits of data to recover the wallet.  Electrum uses 128 bits, which takes 12 words to represent.  If I were to leech the idea right now, the user would be memorizing 50 words!

However, after beta when I get the new wallet format implemented, I'll probably be dropping to 160-bit wallet seeds, which would be about 15 words.  That's do-able.

Just send me an email at etotheipi (at) gmail dotcom, with the word "test" or "testing" in the subject line.  That way I can easily go back later and find all the emails and construct the list.  Thanks!

See the second post on this page.  I describe why I don't want users to do that.  

But I won't be shy about admitting you can still do it -- it'll just take a little bit of work.  Armory assumes that any string entered is a valid wallet, as long as you use the correct alphabet and have a valid checksum.  If you have the skill to reverse-engineer the wallet-restore code and make it work, then I trust you'll use a responsible brainwallet seed  

ALSO:  I want to construct a list of folks who are willing to help me test pre-release versions of Armory.  If you are willing to be part of it, please msg/PM/email me your address.  Like the announcements thread, it should be fairly infrequent that I put out a request.  But it would be awesomely useful if I had a better understanding of who is actually helping test, and whose interested to help with it.

Of course, I do testing myself, first.  But I can't catch everything.

It's on my list of things to do after Beta, to implement a coin-control feature.  Armory (application) asks armoryengine to construct a valid transaction from a list of addresses.  So it shouldn't be hard to just filter that list before it asks the engine for a selection.  Because of that, it's fairly easy to add this flexibility.  I just haven't gotten around to it yet...

---

And a follow up on my previous comments about releasing ... I do most of my testing in Linux (where I do most of my development), and I just noticed a crash in Windows that doesn't happen in Linux.  Therefore, I'm going to have to dig in a bit further before making a release.  Hopefully tonight, still, but debugging rarely goes as planned...

To be fair, I think I've gone to a lot of effort to warn users of stupidity already.  I just hadn't caught this case.

Try importing the same address into two wallets.  Migrating satoshi wallet twice.  Importing a private key with the wrong endianess.  Deleting wallets and address (it's a lot of warning boxes to click through).  Passphrase warnings.  Exposed keydata warnings.  Typo-correction in the entry fields.  Etc.

I know you weren't actually criticizing, I just wanted to point out that I have made it my goal to try to catch everything    Clearly I've got some loose ends to tie up, though (along with a unified backup dialog)

Theoretically: yes

Do I want you to?  no

In fact, I've been having a long discussion with some of the bitcoin-qt devs about how to prevent users from doing this, or avoid the usual issues with it.  Here's why I can't condone pure-brainwallets:

-- Bob A. create's a wallet and wants to never forget it, so he uses sha256("Bob is cool") as the basis for his deterministic wallet
-- Bob A. adds 500 BTC to this wallet then goes to bed
-- Bob B., also a new user has the same idea and creates the same wallet by accident (or, equally likely, a malicious person starts trying lots of common passphrases in sha256(X) to try to find collisions -- you know it will happen [and probably already does]).  
-- Bob B. realizes there's all this money in his wallet that isn't his, transfers the 500 BTC to another address.

This sounds like user error to me.  Sure, it is... but Bob A is not the only one that suffers:

-- Bob A. wakes up to find all his money gone.
-- Bob A. gets on IRC, bitcointalk, etc, and starts crying about his money being gone
-- Bob A. blames Armory for losing his money and claiming the program is insecure and keeps asking me to refund him.
-- I respond by spending 3 days digging into the allegations and trying to discover where the security vulnerability is
-- Other users dive in and start trying to track the stolen coins and posting warnings about Armory and security issues
-- Bob A. won't admit he used a $#!+ passphrase.  It makes him look bad and doesn't get his coins back, so why would he?

No one wins in this situation, except for Bob B.   This is why I'm working with the devs to develop a technique that only 1 out of 2^x passphrases is even valid, thus requiring Bob to either use a real RNG to generate his passphrase, or use a program to find an extra x bits of entropy to add to his passphrase that allows him to use it.

i.e. sha256("Bob is cool") is not a valid passphrase.  But sha256("Bob is cool 1xbnw38kpq") is valid.  It's still memorable, but no one will be colliding by accident and it will slow down malicious users by a factor of 1/2^x, probably making it entirely infeasible.

That's not to say that people aren't doing this now, and not to say it couldn't happen right now and that people won't find a way around it.  I just want to minimize the occurrence of it, and my exposure to it when/if it does happen.
  

---

Fwhew!  Now that that's out of the way.  Think you should know that I'll be releasing a testing version tonight.  Version 0.79.99-almost-beta!  (that won't be official name).  This version will actually be pretty much the same, except it should work on Win32 (though I haven't tested that part, yet), and it will be robust against the B2G bug (like Y2K, but Blockchain-2GB).

All my testing so far has shown that it works with two minor caveats:  

(1) There's some rogue memory allocations that lead to 600-700 MB RAM usage overall -- this should be more like 200 MB after I fix it.  But it will still be usable on most hardware.  It does not appear to be a real memory leak, as the RAM consumption does not increase even when I leave it up for 2 days...
(2) Unconfirmed balances are not computed correctly.   In fact, it's a tad bit confusing.

Neither cases are showstoppers compared to the client flat out not working when the blockchain hits 2 GB, so I will release as is, if I have to.  Though I will try to fix both by the official release.  

Ahh.  I can feel the thought process you went through.  I totally sympathize with you.  I don't know about you, such a mistake could've let to much more than 10 BTC loss!  So, it's not fun, but it could've been worse (always trying to stay positive)

I think it would be pretty easy to add a box to let the user specify what address they'd like to use for the change output.  That doesn't entirely solve the problem, but it would at least serve as a reminder and give you a way around shooting yourself in the foot like this.

I can take it a step further, and add a wallet option/flag that tells it to stick to imported addresses only.  The question is, when I need to create change, how do I do it?  Send to the next address that hasn't had change sent to it recently?  Have the user specify a universal send-change-to address?  Require them to specify it every time?  Obviously, this will be under the advanced interface

P.S. -- I'm still claiming that my program has never been responsible for losing anyone's money.  I'm sticking to that claim even after your report

This should be a non-issue in the long term:  If the network can't handle 50k tx per day, Bitcoin was never meant to succeed.  The only reason it's such a big issue right now is because it's a single entity producing the volume -- and thus there's somewhere to point the finger when it was really our lack of preparation to handle it.  It could've just as easily been a piece of some other market that latched onto BTC and produced 50k tx per day in a less-centralized manner.  

It's a downside of having a completely open, decentralized, apolitical, global currency scheme -- people must have the ability to use it as they please, and the rest of the system must find equilibrium.  Talk of deprioritizing certain behavior, especially targeted at a specific service is completely counter-productive and inappropriate:  people who want to repeat the discouraged behavior will find a way around it, and other people who are otherwise legitimate may suffer by being inappropriately affected by the change.

In my mind, the only reason this is an issue is because the community was not prepared to handle the rapid increase in size -- and it will work itself out once users/dev figures out the way to accommodate it.  There just may be some turbulence in the short-term.  

[For reference:  the idea I proposed is a special blockchain pruning method that allows nodes to verifiably query any address balance with only a couple kB download -- and the pruned data would be maintained & enforced on a second/alternate blockchain using merged mining]

Theoretically, the alt-chain created for this purpose is strictly optional.  No one is "forced" to do anything -- they only use it if they want to participate in creating/exchanging/verifying/downloading address-balance information.  One major benefit of the idea is how perfectly non-disruptive it is.

I agree that it would be complex.  But there's a lot of alt-chains already in existence that use merged mining, which probably provides 90% of the template that would be needed.  I don't mean to imply that there's anything easy or quick about it... just that a lot of work has already been done.

Otherwise, there's two options that both have serious downsides (compared to using an alt-chain).  But maybe some brainstorming can resolve it:
(1) Overlay network like what stratum is trying to do.  Issue:  requires some trust of other nodes, and malicious nodes can really muck up the network.
(2) Modify the main blockchain, forcing block-headers to include a valid balance-tree hash to be accepted.  Issue:  requires a hard fork. 

However, there's a dozen other things that could go in as long as we're doing a hard-fork, anyway.  If there's any inclination to believe it will have to be done at some point, earlier is better...

Fwhew!  I feel a lot better now.  Sorry I had you run through some unnecessary hoops. 

I know exactly what to do to prevent this in the future, and it should only take like 10 min to implement.  It will definitely be going into beta.

Thanks for being patient with me!

Oh!  Try one thing:  delete /home/username/.armory/mempool.bin.  It's possible that file got corrupted on the power failure.  That would be a perfect explanation for this, and if that's it, I think I know how to fix it...

If you could get me what the stack looks like when it segfaults, that would be useful.  I don't know if it works, though, if the program was not compiled in debug mode.  I'll save the details of how to do that until I find out if the mempool.bin file is the culprit...

It is safe to do that, but I have never needed to.  I wonder if it's related to the power failure...

Armory expects to use the same blk0001.dat file as is used by Bitcoin-Qt, and thus making a backup wouldn't really help much.  Personally, I'm not sure why Bitcoin-Qt works and Armory doesn't.  One day, when Armory is independent, I'll have a better chance of preventing this from happening.

If you don't mind, shutdown bitcoin-qt/d, delete/rename blk0001.dat, then restart bitcoin-qt/d and let it re-sync.  Then start Armory. If that doesn't resolve it, then I'll have to come up with something else...

There's no RPC interface like bitcoind has, if that's what you're asking.  Instead, Armory was built off of armoryengine.py (and dependencies of that file in the same directory), which means that ArmoryQt.py is basically just a sequence of python-shell commands that could theoretically be run from the python shell.  Obviously, it's a lot of commands.

This means that there's nothing stopping you from opening a python shell, typing "from armoryengine import *" and then you have full access to everything that Armory does.  It's quite a bit lower-level than RPC interface, but if you're writing scripts that wants to leverage the blockchain scanning or wallet management, it can be done.  I have some sample code in the "BitcoinArmory/extras" directory.  Loading the blockchain, searching for balances and unspent-txouts, importing keys to wallets, etc.  You can create transactions, too, but they're a bit more complicated. 

It is in my plans to make a real RPC interface.  I just don't know when, yet.

I understand your desire to have a clean and efficient PC, and that's why you shouldn't be bothered by this: it is completely benign.  It has no effect on any other program or system component except other Bitcoin programs, and only if that program was planning to be equally offensive (by modifying the same registry entry itself).

Additionally, I'm very concerned that the lack of the URI-handling feature (or a broken one) would cause users to overlook Armory in favor of other programs that do use it.  It's a very elegant feature that streamlines the entire philosophy of Bitcoin for all parties, especially new users.  I want to make sure that when the new user clicks that Bitcoin link, the app "Does The Right Thing" instead of popping up a cryptic error and/or application selection dialog.

With that out of the way:  you will probably still tell me that you don't want it, and I should still make it an option.  Well, I've written it down in my notebook.  Perhaps one day I'll get around to figuring out how to add an option for it (probably another command-line flag).

To be fair, "tracelessness" of Armory is not a goal of mine.  "Portability" is a feature I'm happy to support, but not at the expense of disabling what I believe to be critical functionality for the success of Bitcoin.  Supporting "I've never used Bitcoin/Armory in my life!" plausible deniability is not in my priority list.  No offense...

If I can figure out how to do it easily, I will try to make URI-registration optional.  But at the moment, it's tough to see beyond the impending doom of the upcoming blockchain file-splitting.

I should highlight my favorite benefit of Bitcoin: protection from identity theft.   This is the number one reason I use it (and it was mentioned by someone else, but I don't feel they stressed it enough). 

Not only are your transactions pseudo-anonymous, but you get to send the money to the merchant, not give the merchant your credit card info and unnecessary personal info so that they can store it insecurely and/or sell it to others who will abuse it. 

I don't have to worry about shady business practices signing me up for "monthly" subscriptions to services I didn't realize I was agreeing to in some long-winded EULA and have to sit on hold for hours trying to cancel it and get a refund.  I don't have to worry that the company might accidentally compromise my information, leading to identity theft and damage to my credit that can take forever to get sorted out.

A merchant requests payment and then I pay them.  I don't send them all this potentially-compromising information and let credit card companies profile my every move so they can send me targeted promotional materials or adjust my credit rating unnecessarily.

With control comes extra responsibilities.  But in today's world, people are starting to value individual control/security/privacy more than convenience. 

You have to touch the registry to register an application as a URI-handler.  There's no way around that (that I'm aware of).  And that is the only thing I use the registry for.  Everything else is stored in settings files, as it should be;  in your "<datadir>/Armory" directory.