It's back up, now.

Having some issues with transferring the domain to another webhost, and also setting up some services on it.  There will probably be one more downtime slot in the next week, and then it should be stable after that.  Sorry for the trouble!

It's entirely possible that you have a corrupted blockchain file. I have had this happen to me before -- https://bitcointalk.org/index.php?topic=44887.0 -- I spent like 4 hours tracking this down to a single flipped bit in 2 GB of blockchain files.  I simply redownloaded the chain, and it worked (not so "simple", anymore).

The other issue could be RAM... if you are low on RAM and have no swap space, I suppose it it could bad_alloc because it can't allocate any more resources.

Armory hardly uses any HDD resources.  If you have HDD issues, I would blame it on bitcoin-qt or some other app -- Armory uses about 50 MB total, the rest is RAM.  I suppose if you start swapping, that would cause HDD issues.  However, sometimes Armory can go into freakout mode -- where it hits some unrecoverable error, and it starts sucking up a lot of resources.  One of those, I believe has been fixed -- try going to the bitcoinarmory.googlecode.com page and download 0.87.2. 

Other than that, there's not a lot of useful information in those bug reports.  I know it's never fun to redownload the blockchain, but it is the likely culprit when you consistently fail at the same blockchain location loading.

Oh yeah.  The precompiled version probably won't work on ARM. 

But if it complains about no CppBlockUtils module, it means compliation didn't complete.  Next time you run "make", observe if it spits out any errors (there will be some warnings, but there shouldnt' be any errors).  If it finishes, check to see that you have a CppBlockUtils.py and _CppBlockUtils.so in the base BitcoinArmory directory.  My guess is that it just doesn't finish compiling and you didn't notice the error.

By the way, there's an Armory subforum, so that is a good place for this.

The problem is that the C++ utilities weren't compiled, or failed to compile.  That's why you get that error.  If you type "make" from the base BitcoinArmory directory and you have all the correct dependencies, then it will compile and put CppBlockUtils.py and _CppBlockUtils.so into the correct place to run "python ArmoryQt.py.

However, two things:

(1)  If you just want to run Armory (as opposed to modifying it, etc), you can just download the .deb posted on the Get Armory page.  Just double-click it after you download it, and it will find all the correct dependencies for you and put everything in the correct place.  This is the best option for using it, since it guarantees it will register itself to handle "bitcoin:" URLs.  No guarantee when you compile it yourself.  If you are concerned about authenticity, you can follow the directions at the bottom of the Get Armory page to verify it is signed by my offline signing key.
(2) If you do want to compile it yourself you should follow the directions on building Armory from source page.  Again, you can downlaod the GPG key from any keyserver and verify the signature on the latest Armory tag (v0.87-beta or v0.87.2-beta).  There's very few steps on that page, and they've worked very reliably on debian-based systems.

That's pretty bad news for me.  I have pretty much never used OSX for anything, and if you can't get it working,  I'm pretty sure it's going to be a total bear for me. 

On the upside,  the satoshi client uses Qt,  too (though not python/PyQt),  and they bundle it all up into a pretty OSX package the way I want to do it.   Perhaps we can start from their packaging system and modify it until we get there...  I think Gavin actually responded in this thread a while ago with some links... But I'm on my phone right with poor Internet connection, so I can't really go back and check easily.

Again,  this is something I will make happen at some point but not soon unless users with more OSX experience help.

And Red Emerald, don't feel bad.   You've already helped out so much already!  Without it,  there might not have been any OSX support at all! 

Gavin,

I apologize I haven't been keeping up at all with the payment protocol discussion.  I didn't realize it was intended to be used for inter-party/device communication for multi-sig transactions -- I thought it was basically an extension of PKI so that payment addresses can be secured/authenticated.  For instance, one of the things BIP 10 needs is not only to transmit the transaction to be signed, but also all supporting transactions bundled with it, so that the device can verify the transaction fee.  Is this in scope for the payment protocol?  Regardless, I guess I have some reading to do!

I've been thinking a bit about crowdfunding development activities, based on some conversations with the BitPay guys.  Rather than simply donating money to the active developers, you start "bounties" on various features.  Ideally it would be done with the Assurance Contracts idea -- one website or service could simply be used as a hub for collecting and making available these bounties.  Users commit non-final funds to the contract which is not valid until enough input BTC has been collected, and then it immediately pays out.  The developers of that project, and whoever else are involved then work on that feature and independently decide how to distribute the bounty.  It requires a bit of trust that the lead devs will guarantee completion of the feature once the bounty is collected, but I think the users contributing are doing so because they trust the core devs of that application to follow through and distribute the bounties fairly.  This leaves the burden of "who gets how much for how much work they did" to the discretion of the leaders, who are best suited to making that judgment, anyway.  If they do not behave themselves, the project will suffer when users dont' want to help out and users stop contributing. 

In the long run, it looks the same:  developers do development and get donations.  And users/companies get to "vote" with their money to drive the direction of development.

(FYI, users are "free" to cancel their contribution any time before the contract has matured, by simply broadcasting a tx that spends 1+ input that was used for the contribution -- the service would simply keep a running list of how many valid txouts are available, and can update it in real time -- so unlike Kickstarter, users can uncommit their funds, but the funding levels can be accurately computed and reported in real time)

But of course, no one has the software available for doing the assurance contracts, yet.  Right now, it only takes a reputable organization to manage this and essentially do the same thing until assurance contracts are accessible.  The important part is contributors see their money going to people for doing work on open-source projects.  And when there's a specific task behind it, the devs get good feedback about their own work and users feel like they are getting something tangible for their money.

For reference, Armory's new wallet format (and interface/GUI that uses it) will eventually implement this.  I'm hoping something will be available in the next couple months.  Multi-party transactions are quite a ways down the road, but linked/paired wallets will be implemented right away with the new version.  And with a nice pleasant interface, in the same spirit as Armory's offline transactions (in fact, it can/will use the same protocol for communicating transactions between wallets as it does for offline transactions -- which are really just a 1-of-1 tx being created by a non-inclusive party).

EDIT:  the part about "same protocol" is not entirely true:  BIP 10 was created for Armory offline, with the intention of supporting OP_EVAL (yeah, long time ago).  But it needs to be updated to be more flexible...and hopefully standardized, too.  Hopefully, the devs of other applications will be more interested in helping develop it, now that this kind of functionality is closer to actually being usable.

For more advanced things like "escrow", it's going to take some time work out how to do it "right".  For now, it will probably be a super-advanced interface that consists of a bunch of atomic operations that advanced users can piece together to do what they want, and then me & others can use the experience to optimize it make it better (such as creating a simple direct-connect protocol that executes all the operations and checks under-the-hood).  There's a lot of discussion about it in this thread where Gavin and I talked about how to do buyer-seller escrow without a third party (but easily accommodate a third party if they wants dispute mediation).  The idea is that both parties commit an extra X% to the transaction that they get back at the end, as a "risk deposit" so that the buyer knows the seller is serious, and the seller knows the buyer has incentive to finish the transaction.  And the deposit can simultaneously serve as a fee if there is a third-party and they are needed for mediation.

I'm going to be focusing on the linked wallets first: if Z is a full wallet and Z' is a watching-only/observer wallet, then you would have something like computer with AB' and smartphone with A'B, and all addresses they produce are multi-sig using P2SH, and all the multi-sig details are hidden under the hood.  Or you would have something like three owners of a company using ABC', AB'C and A'BC to control funds of a company in a 2-of-3 tx.  That is top priority.  And then I'll have all the multi-sig support in place to start experimenting with an interface for the other types.

It doesn't look like anyone else is working on this kind of interface, yet.  I guess you can expect Armory to be the first.  Should definitely be done within the next 3 months (for linked wallets).

@ SgtSpike:

Chrisrico hit it right on, but I'll add a link to the Quick Start Guide that I created recently.   It shows a very short list of what you need for online and offline, and has some common questions like yours at the bottom.

@ Everyone else:  I see I missed a lot of messages.  FYI, I am on vacation right now, and have been fairly detached from... regular life.  I will go back through these messages and respond soon.  I promise! 

I've ranted about this before, and I'll resist the urge to ramble about it again, but the gist is:  if there is an encrypted backup option, everyone who's not thinking deeply about it will just use it because it sounds better, and they will end up with no plaintext backup anywhere.  In reality though, if you have no plaintext backup, you have a brainwallet.  Your coins go with you to the grave, or when you forget the decryption passphrase in 10 years (the first time you ever need it).  I believe that it's best for everyone to have a plaintext backup somewhere, and I don't usually support "protecting user's from themselves" (like the drug war, etc), but in this case I think it's preventing a lot of pain. Though, I could probably make some money setting up a service to help people recover their wallets after they forget it...

This is why I was excited about that M-of-N fragmented backups.  Because it really opens up the possibilities for backing up your wallet without effectively creating a brainwallet.

One thing I was thinking of doing was having a screen that says something like: "Print a paper backup with a printer-protection key: create a passphrase that is required to restore your wallet from the paper backup, so that the backup information cannot be stolen by a compromised printer.  Please write the passphrase in the specified area on the paper backup after it is done printing".  This would hide the capability as an extra protective measure, and most users would probably just follow directions and write it on the paper (along with adding extra protection for the Samsung printers with known root exploits).  But an expert user could choose not to write it on there.  That might be enough to sooth my nerves.

This is all coming with the new wallets... if I ever finish them.  It's turning out to be a complete overhaul of some previously-well-tested code, and so it might be a while before I can get them working again (and I probably have to re-write my 1,000+ lines of unit-tests, too).  But I think it will be worth it.

There are two main factors to answering that question/request:

(1) While Armory is still a fairly advanced program and Red Emerald has done a fantastic job helping people get it going on OSX, I have put this slightly lower in priority.  Mainly because I know nothing about OSX, and it's currently accessible to those that really want it.  When I finally get Armory's usability up to par, then I will make it a high priority to bring that usability to all platforms (and right now, there are some pretty epic usability improvements in the works).

(2) Everything I just said in #1 is based on getting no help from anyone else.  If someone else were to make an OSX bundle of Armory for me, and then give me what I need to know to understand how it was made and can rebuild/update it myself... then I can bump it way up in priority.  It's current priority is based on how much else has to be put on hold while I figure it out.  If someone gives me what I need to figure it out in day or two, there's no reason for me not to do it right way.

It's not complicated.  It just means that the webserver can't say: "Please pay this 25-byte P2SH script". Instead it will say: "Here's 3 public keys in a 2-of-3 tx, the CA signatures of those keys, and the multiplier to use for them".  The client will verify the three public keys, multiply them all by the multiplier, then construct the P2SH script deterministically, and then send the coins there.  It also isn't so bad, because it can all be automated behind the scenes, so users won't have to juggle 200-bytes of Base58 data or anything.

You can't really do this for arbitrary scripts.  This works because of the ECDSA multiplication properties that are used in all the other "crypto tricks" throughout Bitcoin.  And if you go back to online-signing keys, then I think the whole exercise is negated:  the whole point of this is so that the signing keys are not on the same system that is distributing the addresses.  Without that property, I'm not sure what we're gaining over SSL.

There was some debate in that thread about it... If it's P2SH, you have to distribute the individual keys that make up the P2SH script and let the user create the P2SH script after they verify all the public keys (and we need to adopt a universal convention of ordering public keys lexicographically in P2SH scripts).  It kind of defeats the purpose of P2SH, but at least you still get the space-savings of P2SH in the pruned blockchain. 

It's not ideal, but it would work as long as all the keys are signed by the the same trusted authority.  If you're talking about arbitrary scripts... good luck with that one! 

It doesn't work because I only recently added the "encodePrivKeyBase58" function and you are using an older version (up until now, I was basically rewriting the encode code everywhere I needed it).   It is available in the latest download, 0.87.

I believe that this thread combined with the payment protocol is the solution.  

Right now PKI/SSL (mostly) guarantees that you are talking with the server you think you are, but it doesn't guarantee that that server hasn't been compromised.  There's nothing stopping someone the attacker from plopping their own addresses in there.

In my scheme, that was similarly described by thanke, you create a root deterministic wallet, and give out just the public key, but not the chain code.  You sign that with an offline signing key (this is the key difference here... with SSL the server must hold the signing key online, in this scheme the signature happens once, offline).  Then the server doesn't distribute addresses, it distributes the root public key (with a verifiable signature) and a multiplier.  The user's software recognizes the signature and then multiplies the public key by the multiplier and sends money to that address.  (the multiplier fits right into BIP 32, I_left, and doesn't give away the chain code so the address chain is still kept private).

Assuming the PKI is implemented properly, that means that client software can refuse to send money to any address that isn't derived from the business's known (offline) public key.  Even if an attacker compromises the webserver, the worst they can do is send a random multiplier to the customer and not record it, thus requiring the business to later contact the customer and retrieve the multiplier (probably the order number) so they can find where the money went.   It essentially enables "secure address distributors".  

I have thought about something like this in Armory.  I figured it would basically be an extension to the payment protocol:   It can easily piggyback off of existing WoT (as Gavin described), and you can keep the spirit of both offline private keys and privacy of your address chains.  


EDIT:  Just to clarify, this technique does not use static addresses.  Each customer gets a different address, and has no way of knowing what any of the other addresses are.  The signed public key that is distributed is never used for receiving coins.

Whoops, I gave bad advice:  if you don't supply any keywords to "wallet.unlock()" it treats the first argument as the "kdfOutput", instead of the "kdfPassphrase" (i.e. it's expecting a 32-byte decryption key where you put your passphrase).  In actuality, your decryption key is your passphrase passed through the KDF, so you need to call it like this:


The function declaration is here.

It sounds like I need to put a check in there to make sure if someone calls with a non-32-byte input, it will bail instead of passing it to the C++ which will segfault (treats it as 32 bytes no matter what).

If you are going to do more scripting with armoryengine, checkout the "extras" directory.  Specifically, for this task, the command-line tx signing script (cli_sign_txdp.py) has most of what you need in it.

One day I'll be able to make developer docs...

The "backup individual keys" doesn't require forethought.  You can always run Armory in offline mode and "backup individual keys' from there.  That requires no RAM, and will work on any computer that Armory can be installed on. 

If you really want a scripted way to do it, you can follow some of the example I posted above, except instead of getNextUnusedAddress() after loading the wallet file, you would iterate through wallet.addrMap and pull out  "addr.binPrivKey32_Plain".  If the wallet is encrypted, those variables will be empty unless you unlock it first: "wallet.unlock(SecureBinaryData('my_secur3_p4ssphr4se'))".  If you want an interactive script, you can use the "getpass" module to have the terminal request a password from you without echoing the chars.

The "..." balance is when Armory isn't done scanning and/or is offline.   If Armory truly believes balance is 0, it will show 0.0.  The "..." means it doesn't know yet.

Looks like you're stuck with the manual method... You can switch Armory to expert mode from main window in the the "User" menu (don't worry, you don't have to restart).  Then when you open wallet it will tell you how many addresses you have generated.  You can click on it to generate as many more as you want.  However... it's going to require a rescan afterwards, because this isn't a normal use case for Armory wallets (it's usually for searching for transactions that may have occurred beyond the last key generated so far from using the wallet on multiple systems).  But it doesn't matter ... you can still go "Backup Individual Keys" while it is scanning and click "Show unused keys" and print off a list of addresses to transfer to the webserver.  It's annoying to have to move the addresses back and forth, but if you can't put anything on the server, there's not much else you can do...

On the other hand, given the limitations you are experiencing... maybe Armory isn't the best choice for you at the moment.  And I'll take this as a nudge that I need to get the RAM thing sorted out...

You're in Armory territory now, and you don't even realize it.  This is exactly where Armory shines, if you are willing to consider a different route than you're taking right now.  I will explain the "correct" way to do this, and if you don't like it, I will tell you how to do it the way you are trying to do it, but I think you'll find your way excessively inconvenient.

The key here is to use  "watching-only wallets" which are copies of a regular Armory wallet that don't have the private keys.  It generates the same infinite chain of addresses as the full wallet, but without the risk of an attacker getting the private keys if they compromise your webserver.  And you can monitor the payments from multiple computers.  It's really got all the convenience and security you can ask for... if you do it the Armory way.

(1) On any computer other than the webserver (preferably offline), create a new Armory wallet.  No need to import any addresses.
(2) After creation print a paper backup!  It's the safest and most convenient way to backup your coins forever.  Digital media can fail, and printing thousands of keys will be a disaster to have to reimport later.
(3) In wallet properties, click "Create watching-only wallet".  (probably use USB key if offline)
(4) Transfer the watching-only wallet to webserver and if the original wallet is offline, also import the watching-only wallet into Armory on your online computer
(5) On the webserver, you can run a very simple script to generate as many addresses as you want, all protected by the paper backup, and without containing any private keys.  Install or download&compile Armory on your webserver, then run this script every time you want a new address (you may have to modify paths appropraitely):


The beauty of this is that the moment someone sends money to any address that your webserver generates, you will see it in Armory on your primary computer (using either watching-only or full wallet).  And if you keep the full wallet offline, you're about as secure as you can get.  If you want to create addresses manually on some occasions outside the webserver, just create a new wallet on your primary computer and use that (or rather, create a second offline wallet and import that one only on your primary computer).  

If you run a webstore, you absolutely should not be using online/web apps to generate addresses.  There's too many ways for that to be compromised, especially when there are tools like Armory available.  There's a JSON-RPC version of Armory (armoryd) available that will make this easier in the future, but it's not completely stable yet (crashes about once a week).  I'll let you know when it is stable if you want it.

---

EDIT: Duh!  If you want to access the Armory address chain through JSON-RPC, armoryd.py will work perfectly stable in offline mode (the instability comes from fighting with Bitcoin-Qt over the blk*.dat files when online).  If you, or anyone else reading, wants to access Armory watching-only wallet addresses using JSON-RPC and don't need network connectivity, I will commit an armoryd.py that works in offline mode, shortly.  It's basically already done, I just need to tweak it and test it.

EDIT 2:  So apparently it already works.  You just need to checkout the "testing" branch from the github repo.  On your webserver from the checkout directory:
Then setup your JSON-RPC process to use the username and password in /home/user/.armory/armoryd.conf (the file should have one line, "username:password").  
Then you simply keep sending "getnewaddress" commands and you'll be receiving new addresses every time.

If the addresses were imported successfully, Armory will see them after the next full scan.  I realize that's a lot to ask for in your case, but it has no way to know its balance until it does.  It should have seen it the first time.  If not, it's probably a bug, but it most definitely will see it after the next scan (if somehow the addresses didn't get registered in Armory before the last scan).  

3GB used to be enough, but I guess the blockchain has grown enough that even that is borderline, now.  All the more reason I need to get the file-based blockchain management integrated, ASAP.

On a side note:  I recommend not using bitaddress.org private keys.  You are nullifying many of the security benefits of Armory doing so, and it's not necessary -- Armory wallets will generate an infinite number of addresses for you, and you only have to print that one sheet of paper to protect all of them ("Wallet properties"-->"Print paper backup").  If you decide not to use Armory later (say, because I haven't fixed the RAM issue fast enough), you can go into the wallet and "Backup Individual Keys" and it will list all the keys that you have used so far -- then you can copy them out to import into another application.

In fact, importing those addresses won't do you much good anyway.  When you send coins, change is sent back to an address in that infinite chain.  And when you click "Receive Bitcoins", it will give you an address in that infinite chain (the one protected by your paper backup).  Importing keys is really more suited to having vanity addresses, or specific donation addresses you wanted to bring over from other applications, etc.