Any printer has cache, some heavy duty enterprise level printers come with a harddrive. Regardless of the printer, it is reasonable to assume some of the data you have printed may still be within the printer's memory until you override it. SecurePrint ensures that data is encrypted.

It is also useful for network printer, which require you to expose the data to print to your entire network.

Armory wallets are deterministic. You do not need to print the private keys the wallets hold, only the root keys. There is a "SecurePrint" feature with printing paper backups for that purpose.

For the paranoid kind, you can always print a few pages full of characters to overwrite the printer's cache.

I do not think there will be an issues if both Armory and counterpartyd are run separately. I'm not familiar with counterpartyd so I can't tell you for sure if it can be run concurrently with Armory.

I suspect counterpartyd connects to bitcoind through the RPC, so will require login/password settings that will conflict with Armory when it is auto managing bitcoind. Turn that off and you shouldn't have problems.

bitcoin.conf?

Do you mean this WO is ages old? I thought you had it exported from your recently restored wallets. If it is very old, now I really want to take a look at it.

Someome just recently sent us a WO that crashes Armory. I don't know if its yours but I'll be getting on it soon. I'm not gonna insist to see your WO until I'm done with the current one, however it may be very interesting. If anything don't delete it.

As for your test, you should try with a freshly derivated WO.

Deleting BitcoinQt != deleting the blockchain, so just making sure: Did you delete and redownload the blockchain?

Did you restore you backup before or after you Armory built its DB? Have you tried with a watching only wallet?

Try that again with a watching only copy of your offline wallet. If that crashes too, send me a copy of your WO wallet and I can isolate the bug.

Gone through your log file. This is caused by a bug that has been reported like a week ago. It's on my todo list after Im done with my current task. So I'll have more for you sometimes next week most likely.

For now, as I suggested, make sure you have at least one wallet loaded before letting Armory build its DB.

All of yo look like you have malformed blocks in your local copy of the blockchain. You're gonna have to delete it and redownload it.

wheeler: As for your private keys, you can use the new backup center feature to extract your private keys in version 0.90. Make sure to start it in Expert mode, then go to your wallet properties, pick 'Backup Wallet' then 'Export Key List'

In your .desktop file (in usr/share/applications), on the "Exec=" line, add your command line arguments before the %u

Copy paste the content of the .desktop file in here. Type this in your termina to open itl:

gedit /usr/share/applications/armory.desktop.

Do the Armory offline or Armory testnet icons work?

Delete your local copy of the blockchain.

Nvm the first part. Just have that wallet sitting in Armory's datadir before building Armory's DB. Also, send me your log file at support@bitcoinarmory.com, link to your post so I can recognize you.


Does it crash or do you terminate the process yourself? Assuming the process is hanging, is Armory maxing one of your cores?

Delete your local copy of the blockchain and let BitcoinQt sync again.

You can simply start Armory in Offline mode and extract the private keys. If you have start up issues, delete the databases folder in Armory's datadir. If your scanning gets stuck, you most likely have malformed blocks in your local copy of the blockchain. We're working to fix that, however redownloading the blockchain fixes that usually.

This information is available in the Troubleshooting and FAQ sections of our website.

You can't really take code out of github. People can always pull earlier commits. Github has this politic of never deleting anything pretty much.

Traceback (most recent call last):
  File "ArmoryQt.py", line 4684, in Heartbeat
  File "ArmoryQt.py", line 1917, in finishLoadBlockchain
  File "armoryengine.pyc", line 7851, in fillAddressPool
  File "armoryengine.pyc", line 7817, in computeNextAddress
  File "CppBlockUtils.pyc", line 1164, in addScrAddress_5_
TypeError: in method 'BtcWallet_addScrAddress_5_', argument 4 of type 'uint32_t'

This is an entirely more interesting error, I'll get someone on it, thanks for the log.

Edit: Guess I shot myself in the foot with this one. I hoped to get someone else on this issue but I got 'volunteered' for it =P

At any rate, thanks for the log files. The more details you can give me about your use of Armory before the crash occurs, the more clues it'll give me

We hope sometimes in February, but nothing is set in stone yet.

We're hoping to have a full Mac support by 0.91, which is the next release.

Has quite a few UI related issues still. We recently got someone full time on it so the future is bright on that front.


Not too sure what you are describing here.

This is how you should be going about it anyways: Create your wallet on your offline machine, create a paper or fragmented backup, verify the backup, then create a watching only wallet of your wallet and take that your online computer.

You can outright copy WO wallet that file to your datadir or import it through the import option.

If you have a wallet which private keys have been exposed to the network for a long period of time I'd suggest just moving these funds to a proper offline wallet. You can get rid of the private keys through Armory. Pick Delete/Remove this Wallet in your wallet properties window.

The empty queue is not an error. Queue.Queue raises when it is empty, that's just its mechanism to report there's is nothing left to pop.

The version your reported for BitcoinQt is actually Qt's version, not Bitcoin.

You have to describe your behavior before the crash first. Then possibly send me a log file at support@bitcoinarmory.com