First, run Armory without managing bitcoind. Then start BitcoinQt and let it sync. Then start Armory with the -rebuild argument and see if it crashes.


You should send your log files and detailed steps of the crashes to the support channel: support@bitcoinarmory.com

Worst case scenario, Ill build a PortAudio Python library and get it done that way.

Coin control lets you pick the address, not the particular output. Your best bet in this situation is to wipe out the entire address balance I guess.

Alan is working on it as we speak, hang in there =)

For now, try to run BitcoinQt on your own and turn off the 'manage bitcoind' option in settings, see if that fixes it. Also get rid of bitoin.conf in your bitcoin folder if there is one

Fair enough

The coin control feature gives you a work around to prevent mixing outputs. I guess we could add that option at some point though.

It shouldn't be hard to implement, but it'll most likely have to wait for the new wallet file format, as we shouldn't be going around adding features to a wallet format we intent to upgrade to begin with.

Synchronization servers and lite-nodes will cover that use case.

Offline signing is done by passing raw unsigned transactions to the offline machine. As long as the current transaction format remains valid in the blockchain, you wont have any trouble on that front. Keep in mind that you have to stick to those transaction formats supported by the version of Armory you are running, i.e. dont try to pass a multisig transaction or use compressed keys with a version of Armory that doesnt support those.

You should be fine with that scenario. You can also add the offline package to your live usb. Make a second partition on the USB key and keep all your extra files over there. Then mount it and use.

there are a couple switches:

--datadir defines the location of your entire datadir, meaning db, settings and wallet files

--dbdir defines the location of your database files only

1) No one answered because the whole team was at the InsideBitcoin conference in Vegas

2) Armory isnt crashing, it's hanging, i.e. it is caught in a n2 operation bug, which makes it take a very long time to unlock wallets in certain circumstances. This issue has been fixed. The fix, along with a wallet recovery tool, will be added to the next release

3) Usually in those cases, Armory getting caught up in a very long computation, your OS sees that it isnt responding anymore and assume it has crashed, offering you to kill the process.

4) Ungracefully closing Armory will have you rescan your tx history on the next restart, to make sure the DB wasnt corrupted (in case of an actual crash)

5) You can always try to get us on our support channel: support@bitcoinarmory.com

6) This is free, open source software. Have some patience with us, we cant just afford a 24/7 support channel.

7) In case you dont want to wait for the n2 operation to complete, restore your wallet from a paper backup.

Automatic: corrupted DB on Armory's side. Your best bet it to delete the db folder, or as you did, force a rebuild with the --rebuild switch. If it happens again, catch us on the support forums and dont wipe the db just yet, we may want to have a look at it. You can build a new db in another folder using the --dbdir switch

Just got back from the conference. Alan will still be busy with that for another day or 2 (I left Vegas right away, the rest of the team is mostly leaving on friday or saturday).

Ima try and catch up on the questions as well as I can:

neostatus: at this point turn off bitcoind management in the settings, start BitcoinQt, let it sync, then start Armory.

cypherdoc: it shouldnt significantly differ in speed

Is 0.9 stable: yes, it is a fully fledged stable release signed with our offline Armory GPG key.

LvM: havent fixed that part of the updating process in a while. Alan is on it.

WinXP: full support in 0.91. Build process is ready and functional, so essentially it works in house, just a matter of getting to the next release.

As for using older Armory versions on your offline machine, there is no issue on that front, you're just missing out on the next backup feature, and eventually offline multisig signing.

matt608: make sure you're running ubuntu 10.04 or 12.04, then grab our offline package off our site and follow the instructions. They're quite simple and you shouldnt have too much trouble setting it up. If you have issues, let us know at support@bitcoinarmory.com

superbit: we're aware of that, should be fixed by 0.91

About BitcoinQt 0.86: there shouldnt be any compatibility issue on that front, but we need to update to the newest fee calculation on our end as well.

Tamis: the team is slowly getting back from Vegas, expect us to be fully responsive starting next week.

Kluge: --datadir sets your entire data folder to another location (settings files, wallets n all). You can use --dbdir to specify a folder for the db only

OSX users: hang in there, you should have support in 0.91 =)

Glad to hear it worked. The whole process may still be a little shaky, so let us know about your full experience on support@bitcoinarmory.com so that we may cover your scenario in later releases =)

You shouldn't use a custom bitcoin.conf when you let Armory manage bitcoind. Otherwise manage it yourself and turn off the feature in File > Settings in Armory.

With Armory running, go to File > Export log file, and email it to us at support@bitcoinarmory.com

That's our current stable version.

What it all boils down to is that open source software allows you to manage your own comfort zone in regard of the code you're allowing to run on your machine. You can choose to trust the code maintainer, or people who have reviewed it, or just not trust anyone and verify critical parts yourself.

You don't have to unless you want to use the feature. If you're fine with single sheet paper backups, there's no need to move to M-of-N. The later isn't replacing the former, it's an added feature.