There's a support channel for these matters. If you still choose to resort to a forum post, the least you could do is to provide proof of what you are purporting, and attach some log files.

For various reason, not only privacy, it's about time the community moves on to BIP32 wallets. Can't really point fingers as we are lagging behind currently (not for long though!).

You're exposing your private key to an online machine. If you can't see what's going wrong here, you need to do more research. You are literally negating the whole cold storage part. Also, using a single address is bad for your privacy, and the privacy of everyone who trades with you.

On a side note, we have some massive backend overhauls coming in soon. We're considering striking the beta tag off once the improved code is hardened and thourougly tested.

That doesn't change the fact that you are running this code at your own risk. I think a lot of open source projects defer responsibility to the user, but I digress.

Due to Bitcoin's decentralized nature and how we work with it, we can't realistically accept the ultimate responsibility of your coins. We simply lack the technological "jurisdiction" to properly investigate a case of coin loss, and have to trust end users word for more than we are comfortable with. It would waste a huge amount of man power to deal with weekend con artists.

Insurance comes a cost. Conventional financial tools and services are insured at a cost to the end user, in the form of various fees and legislations, which trickle down to customer. They also rely on centralized architectures that offer an extreme level of damage control to the service providers. Simply put, the risk is easy to calculate, and the central authority has the power to revert the damage.

On the other hand, charging for pure bitcoin services is hardly sustainable. The technology is open source and decentralized, and purely software. The barrier to entry is essentially inexistent. Competitors would take over your market share in no time. We can't realistically charge you for insurance to cover ourselves.

Neither the technology nor the economic model support what you have been used to for so long in the fiat system. The protection we offer is raw technological performance, without legal nor implementation boiler plate. If you do not understand the technology, or don't use it as intended, we can't do anything for you.

I think insured Bitcoin funds will only apply in 2 cases: at the customer level with centralized services, and at the business level with trained and trusted operatives who will manipulate the funds within precisely defined steps, in accordance to the insurer and technology provider's strict guidelines. I'd be wary of a service that guarantees your coins outside of these parameters.

Make a ticket, add your log. Verify in the bottom left corner drop down list that "all wallets" is selected.

You shouldn't be concerned

It uses about 50MB RAM on its own, plus whatever your wallets' kdf is set at, assuming you encrypted it and will use your pi to decrypt it.

My quote also implies that we can't just implement a random fix and call it a day. It needs to integrate with the model properly and be thoroughly tested. There has been quite an effort deployed to overhaul the backend, which should hit the next release. It will offer a lot more stability, speed and scalability. Scalability we can leverage to implement other sources for the blockchain data and hybrid modes, in a way we think is robust.

The DB version of Armory was introduced in 0.90, and it should be overhauled for 0.93. You are using a proof of concept version and will get to enjoy the rock solid implementation in 0.93. This is the speed at which we deploy releases, and keep in mind 0.90 was essentially a single man effort. Generally the full blockchain approach was the cheapest solution to implement, and  these kind of choices are easy to make when you are putting a proof of concept together. 0.91 was mainly a 3 job, and the whole team of 5 worked on 0.92. Now that we are functioning at full capacity, a lot is getting improved, and much faster.

Also, before we go after this particular issue you suffered from, we had to address the scalability issue that affected a lot more of our users. In contrast, your issue is actually fixable at the cost of a fresh blockchain download, which we did speed up with an integrated bootstrap downloader in 0.91. Keep in mind we identified this issue while deploying 0.90 test releases. This is isn't ideal of course, just side stepping the issue, but cheap enough that we offered this solution while working on something a lot stronger.

Along with the BIP32 wallet version, so either 0.93 or 0.94.

My understanding is that to broadcast the signed tx, you need to load Armory with at least a WO copy of the corresponding wallet

A few short disconnects from bitcoind? That's a benign bug that shouldn't get in the way. It happens on every platform and setups (Win8 RAID0 here), and my old system too (Win7 and single SSD).

What you want to delete is /cppForSwig, which has all the C++ code and compiled intermediary files. You can also get rid of /pytest and /extras, and the obivous windows and osx build folders.

For some reason the bitcoin folder autodetect code fails and passes None to the backend, which crashes. So far we have never experienced the issue in house. A few users have reported the issue but we couldn't guess much from their setup. It may get to the point where we'll put out a high verbose debug version and have you guys run it to give us a clue...

Some failure in the auto bitcoin folder detection.

Force the bitcoin path with the --satoshi-datadir=*bitcoinpath* command line

Maybe, but this definitely isn't a priority for a months to come

Conversation starts here:

https://bitcointalk.org/index.php?topic=56424.msg7307141#msg7307141

Make a ticket, add in a few screenshots demonstrating the differences.

https://bitcoinarmory.com:8443

With the upcoming change to the messaging format to support multisig, anything 0.92 and above will be incompatible with older versions.

Oh boy... not quite there yet, wait till we get a Debian package out first o.o

You can add imported private keys to a paper backup, but you'll end with extra pages. Also you cannot be under the assumption than an already existing paper backup will cover newly imported private keys, which implies you'll have to print new ones every time.