Sorry, I should've been clear... the 32-bit version will work fine offline because it uses no RAM or other resources in offline mode... but most people download it to use it offline and then send me nasty emails about the results.  So I removed it and send the link to people like you

You won't be able to run the 64-bit version on 32-bit (though, typically 32-bit apps can run on 64-bit Windows).  You'll need to download the new version... and/or use the latest version just posted (0.89.99.14 ... soon to be .16).

I'll let goatpig explain about the XP issues -- basically our new build system doesn't natively support it.  Luckily, Goatpig appears to have a solution!  We'll implement that in 0.91 (after this release).

As for the backups: yes, wallets created with the new version only contain the root key.  The chaincode is now derived from the root key, and thus does not need to be backed up.  The system detects whether the chaincode needs to be backed up, and then prints a 4-line backup if it's needed, 2-line backup if not. 

I know it's confusing, but there was really no reason not to do it, besides the confusion around questions like these!  You cannot create a 2-line backup with wallets created with 0.88.1 earlier.  Yet, backing those up with the new system (with SecurePrint and/or Fragmented), still work, and will use four lines. 

When in doubt, use the backup tester!  I put it in to calm users' nerves about issues like these

You can find a 32-bit version on the old google-code download page:

https://code.google.com/p/bitcoinarmory/downloads/list

It didn't post it to the website, because I didn't want people to think they could use the 32-bit version online, because (in 0.88.1) it used 6+ GB of RAM.  The new version works in both 32-bit and 64-bit. 

It is only recommended you use "Import" when you are sure you're the only person who's ever seen the private key, and you plan to use it again.  Since address re-use is discouraged, the only real reason would be for vanitygen addresses which are frequently used without.  Otherwise, always sweep, especially for Casascius coins and paper wallets which have been passed around.

WHy?  Because it's extremely dangerous to add private keys to your wallet that other people have seen.  You open yourself up to situations where someone "sends you money" by sending it to the address that they have the private key for.  It shows up in your wallet and looks like it's yours.  You act on the assumption that the money is yours, then they sweep it back to their own address.  This is a major attack vector against someone who accepts large amounts of money for services.  You pay, they serve, you sweep, they're screwed.

And don't fall for the argument that "all keys should be held on forever in case someone sends more money to it."  Someone randomly sending money to a private key that has become public is like dumping money on the ground.  Any actions you take to "watch that address" is like walking around your neighborhood every day hoping someone accidentally dropped $1 bill.  One day you might get lucky and find $1, but you have better things to do with your time, and it's best not to pollute your wallets with mixed-origin private keys. 

You want to know that when you receive money to any of your wallets, it's really yours.  If there's no reason to believe the key will ever be used again, sweep it.

Well, we naturally recommend Linux for the offline computers, and we've gone to great lengths to make it as easy as possible (default OS install options, unpack and run offline bundle from website).  But it's not a good recommendation if you have never touched Linux before, because inevitably you have to do some other things in the OS occasionally, and it can be scary

32-bit vs 64-bit doesn't matter.  There shouldn't be any performance or security difference between the two.

When you go to a store and try to pay for your candy bar with a $20-bill, the cashier takes your $2.29 and gives you $17.71 change.  This is the same thing: your outgoing transactions have to combine multple previous transactions (bills) to pay the target amount, but frequently overshoot.  For instance, when you try to pay for 0.1 BTC, you might have to use a 3 BTC input to construct the transaction, then you'd actually create two outputs fro the tx:  0.1 to the target recipient, and 2.9 back to yourself. 

Armory creates a new address in your wallet (always protected by your paper backup) for these change outputs.  It marks them with that comment so that you know you didn't create that address yourself.  All of them are still part of your wallet and [most importantly] are still protected by your paper backup.  It's just a quirk in the way the Bitcoin transactions work.

Did I miss something or did you?  The only thing this does is simplifies things for the signer, and negligible impact for the verifiers.  The verifier still has to go fetch the previous TxOut to get its scriptPubKey to cram into the TxIns before signing.  All this does is say "if this SIGHASH bit is on, also grab the value from that TxOut and prepend it to the scriptPubKey".  That simple change allows an offline signing device to sign transactions confidently without having to see the entire previous transactions being spent.

I was talking about from the wallet design perspective.  Multi-sig & P2SH increases the complexity of the app.  This change is trivial leverage in your software and dramatically simplifies it.  I assure you I understand that any such changes are "not trivial" to implement in the protocol.  But it certainly doesn't hurt that it's so simple in concept...

There is exactly zero problems mixing and matching operating systems and Armory versions.  The communication between online and offline computers is done through pure-ASCII files on USB, and I don't think the protocol has changed one bit since Armory was released 2 years ago.  So even ancient versions of Armory can be used on the offline computer, with the latest on the online computer.  And as long as both OSes read and write ASCII files, there's no problem there either.

This is why it's rarely necessary to upgrade the offline system.  ECDSA signing hasn't changed, and BIP 10 hasn't changed (though it will with the new wallets, BIP 32, payment protocol, and multisig!).  However, I have added some extra things that help offline signing; like popup warnings when transactions exhibit suspicious patterns, etc.  But it's not critical to upgrade it.  

The exception is this version I'm about to release: some people may optionally upgrade because they want the fragmented backup features.

Slightly off-topic, but if it wasn't for the rapid blockchain growth and my procrastination in fixing Armory's scalability issues, I'd have Multisig-with-P2SH implemented already.  The problem is not the features being useless or unwanted, it's that there's such a shortage of human capital to make progress in this part of the Bitcoin development world.  There's so few environments where such a feature could be implemented, and so many other priorities of the few people developing those environments.

However, this particular change is trivial to implement, and dramtically simplifies implementation of any kind of offline signing device.  There's no doubt it would be used immediately by Armory and all the HW wallet developers.

Note, the disappearing tx bug has been found!  Just posted about it in the other thread.  Rapidly getting closer to a releasable piece of software!

FOUND!  Bounty off.

Sadly, I actually found this bug yesterday, but thought that its behavior would occur 100% of the time I did some specific behavior.  When I tested and it didn't happen, I assumed that wasn't actually a bug (or the bug).  It turns out that was it after all, but it only triggers under very specific, infrequent conditions.  Frustrating! 

Also, CircusPeanut fixed the restore-backup entry fields misbehaving (putting the cursor in the middle of the input mask fields, instead of at the beginning).  That should remove some extra confusion (a lot of people got really tripped up by that!).

Will be attending to some of the things found in the bug-bounty thread and then will release a final testing version before the official 0.90-beta release.  There are still problems with the release, but at some point I have to just release it.  And this version has more than enough usability to replace 0.88.1 on the website.  Exciting!

Just posted signed installers, and hashes files.

https://bitcointalk.org/index.php?topic=299684.msg3657358#msg3657358

POSTED SIGNED INSTALLERS:

https://bitcoinarmory.com/download/

Since the installers are now posted on the official website, I decided I should go through the effort of offline-signing everything, even though it's not the final release.    You can download the SHA256 hashes file here (now with a note to reduce confusion about which hash function to use):

https://s3.amazonaws.com/bitcoinarmory-releases/armory_sha256sum_hashes_0.89.99.14.txt.asc

Note that the .deb files changed hashes since yesterday, because I took the liberty to GPG-sign (using dpkg-sig) the .deb files.  You can use "dpkg-sig --verify *.deb" to check them.  If the signature is good, you don't need to mess with the hashes file.

The only "workaround" is to wait for version 0.92-beta when we implement the new wallets and add native support for compressed keys.  There is just not any good ways to backport the old wallets to use them, that would be easier than just finishing the new wallet format (because there's such exhaustive testing that goes into changing wallet functionality like this, I'd prefer to just do it once).

Sorry, you'll just have to be patient!

First of all, this is the thread about running Armory on testnet!   I think you posted to the wrong thready by accident!  Move your reply and to the RAM-reduction thread and I'll move mine!




So I don't usually go through the effort of signing the testing versions, but since they are posted on the website I will go through the effort.  I definitely should've done that (but I've been rather busy recently and it slipped my mind)...

Though, the tar.gz package is a good idea.  I hadn't thought of distributing one of those.  Also, compiling on Linux is pretty darned simple.  It's five lines at the terminal to install all dependencies and build (though I haven't tried it on 10.04 in a while, but I never had a problem with it).

I'll get some signatures on those things right away.

If you want to run Armory on testnet, you'll have to disable auto-bitcoind and run Bitcoin-Qt or bitcoind in testnet mode manually.  And especially confusing is the fact that Armory and Bitcoin-Qt/bitcoind use inconsistent command line arguments.  For instance, you use "-testnet" flag with Bitcoin-Qt/bitcoind and "--testnet" flag for Armory (yes, one slash for bitcoin, two slashes for Armory).  To be more explicit:

• Armory.exe --testnet
• Go to settings, unselect "Let Armory run Bitcoin software in the background"
• Close Armory
• bitcoind.exe -testnet
• Wait for it to synchronize
• Armory.exe -testnet

Due to some quirks in the path resolution, if you want to use a custom directory for Armory and Bitcoin, the --datadir and --satoshi-datadir arguments are inconsistent.  For instance, if you moved both your bitcoin home dir and your armory home dir to F:\Bitcoin and F:\Armory, respectively, do the following:


The problem is that Bitcoin-Qt expects the base bitcoin home directory, even for testnet, and will add the "testnet3" for you.  If you specify F:\Bitcoin\testnet3, it will run in F:\Bitcoin\testnet3\testnet3.  But I did not realize this when I setup the code for processing arguments, and Armory requires explicitly specifying the full path. 

Sorry guys, I dropped out of contact for a while to try to get some coding&development done.  I will get to all of the posts here eventually.   For now, I would just like to post a 0.2 BTC bounty as described in this post.  This bug is holding up the release schedule, and I can't reproduce it reliably. 

Many of you have reported this occurring at some point.  But I still don't have a solid pattern for it.  I have a couple things I think might fix it, but I won't know if I've fixed it unless I can reproduce it!

If you have gotten Armory fully online and can do some testing for me, help me find the pattern and claim the 0.2 BTC!

Hi barwizi,

I'm not sure exactly what will need to be done, because it's very dependent on the alt-chain you're developing for.  If it was something like Litecoin, you would change the header hash calculation.  Regardless of the alt-chain, you'll have to modify a bunch of the constants in the C++ and python code (magic bytes, address prefix bytes, port, genesis block).

Just some background on how the code is laid out:

Armory's primary goal was to implement as much as possible in python, because of the ease of implementation, error handling, corner cases, flexibility, etc.  However, python is dirt slow, so all the blockchain processing and crypto was implemented in C++, and pulled into the project through SWIG.  As such, the code is split into

C++ (in cppForSwig directory):  This where TheBDM is stored (The BlockDataManager).  It does all handling/scanning/tracking of 15 GB of blockchain, tracking of address balances, unspent output lists, transactions histories, ledger entries, zero-confirmation transactions, etc.  And it is where the crypto operations are executed (EncryptionUtils.h/.cpp).  All these things are accessed from python as if they're native python objects (thanks SWIG!).

Python (mostly just armoryengine.py):  Most everything else is in the python, with all the core in armoryengine.py.  ArmoryQt and qtdialogs is all GUI-related stuff, and may require only minimal updating.  Updating armoryengine.py is where most things would probably have to happen.  This is where the wallet format and operations are defined, interfaces to TheBDM, networking with Bitcoin-Qt (minimal), transaction processing, creation and verification, file formats, etc. 

Per my original statement, what will have to update the constants in the python code, and also pass those constants along to TheBDM so the C++ code is operating on the correct blockchain.

Armory is big and complex.  It will take some time to get into it and understand all the parts of it.  Sometimes I wonder how I'm able to keep track of all of it!   

For reference, I specifically recall retep talking to Gavin about it on IRC shortly after his last post, and Gavin agreed that modifying the SIGHASH system was a bad idea.  I didn't feel like pressing it, at the time, though.

That's not to say that this can't be done or that Gavin and the other devs aren't persuadable.  But it would mean mobilizing support for it and presenting a strong case to those that are against it.  If the system was built with feature from the start, we'd all be happy and no one would have an issue with it.  It's more about convincing folks that the benefit is worth the trouble of making the change.  As you said... the people who most strongly support this are the ones actually developing software that has to deal with the megabytes of supporting transactions just to verify a few bytes.