OP: Why did you remove the oh-so-clever memes that were up late last night, showing skeletons representing the bodies of people who never finished syncing? Perhaps the time you spent getting the bile & rage going in your system would've been better served reading earlier posts. If you had, you'd have noticed you're not the only person who has had this issue. (Granted, I admit we could do a better job of explaining certain issues in a more public manner.) Oh well. The pics are here and here in case anybody wants to check them out.

As goatpig said, the Core corruption is beyond our control. We used LevelDB in 0.90-0.92 and migrated to LMDB (a much saner DB) in 0.93. We're working on improving our response to Core corruption. There's only so much we can do, especially on Windows, where LevelDB is a total disaster. Also, while firing off your vague set of specs last night, one thing you forgot to mention was whether or not you're using an HD or SSD. The latter will handle Core and Armory much more gracefully. (Again, this is something that I admit should be explained in public more clearly.)

I'm sorry you're having issues. I also don't know what to tell you, especially if I'm just going to be carpet bombed with profanities in the reply.

I'm unaware of any successful hacking attempts made against Armory. The only possibility I can think of would be one where somebody has an unencrypted wallet that gets copied when somebody has physical or remote access to the computer. The solution in that case is quite simple: Encrypt your wallets with a passphrase. You should never have an unencrypted wallet without very specific reasons, and an unencrypted wallet should never hold more coins that whatever you're willing to lose.

Or, as the last poster said, I suppose a keylogger could steal your passphrase. Not much we can do there, unfortunately. It'd be cool to add some code that understood one's typing cadence and such, and could tell if somebody wasn't you. I'm not going to write that code! (Hell, short of hiring a real expert in that particular field to write it, I'd object to such code being in Armory, period.)

Interesting idea. Admittedly, I'm not entirely sold on the idea of a separate package. There's too great a chance that people will be lazy and leave two copies on their system, potentially leading to weirdness down the road. For example, if somebody had 0.93-testing and tried to go back to 0.92, the Armory DB would keep getting nuked and lead to constant rebuilds.

Unfortunately, I don't think "But only people who know what they're doing will install it!" is correct. It wouldn't be hard for us to miss posts on, say, Reddit, and end up with somebody suggesting people try a test version that fixes one problem but introduces another.

(Just FYI, Reddit was just an example. Some of us do check Reddit on occasion. We typically prefer this forum, though.)

That said, it's something to keep in mind moving forward. Pros and cons, as always.

goatpig can correct me if I'm wrong but my understanding of this is that your blockchain is corrupt. Long story short, Bitcoin uses LevelDB to organize the blockchain, and LevelDB is a massive pile of junk. (Armory also used LevelDB from 0.90-0.92. 0.93 uses LMDB, which is much saner. Anyway....) LevelDB can be easily corrupted, especially on Windows. So, you may have to download the blockchain again and hope for the best. Again, goatpig can correct me if I'm wrong, and give you more specific advice.

There were some issues with the release scripts that have been fixed. It needs to be discussed internally but I don't see why these changes can't be added to the next release.

Thanks. I'm sure we'll get the word out once we're ready to handle translations.

For offline machines, yes, this is basically correct. There is a bug (fixed in 0.93.2, IIRC) that does affect signatures and has a 1-in-256 chance of being triggered. That could be a problem depending on luck and how often transactions will be signed. (Then again, the bug may have been introduced in 0.93! I forget exactly where all the code was introduced.)

That script also requires some extra attention if you want to create an offline bundle. This link (WARNING: Massive amounts of techno-babble) and some follow-up posts roughly describe the process for building offline bundles.

The work isn't finished. Long story short, the ideal solution is to upgrade the Armory codebase to Python 3, which has much better internationalization/Unicode support. It's far more difficult under Python 2, and prone to weird bugs too. IIRC, we had one translation (Icelandic?) we tried sticking in. We found that it broke a lot of our code and had to abandon it.

The aforementioned Python 3 upgrade is something that must come sooner or later. The question is when exactly we will make the jump. It definitely won't be in time for 0.94. Honestly, I'd be surprised if anything is released before the year's out, but that's just a personal opinion, not official policy. I've been surprised before.

Ah ha. That is definitely Armory code.

AFAIK, XT hasn't changed the names of any of the binaries. You may need to use command line args like "satoshi-datadir" to point to particular directories, and maybe turn off auto-management and run bitcoind manually. (I don't remember offhand if you can tell Armory where to find bitcoind. I think you can.) That should be it.

Okay. Here's my understanding. Core already does a lot of heavy lifting. It validates blocks, does a lot of work to validate the transactions, etc. It wouldn't make sense for us to turn around and say, "Well, we need to do our own block verification scheme." Instead, we trust whatever comes out of Core, although we obviously need to have some processing logic in order to read the blocks and transactions, along with writing transactions.

In addition, when creating a Tx, we don't actually fire it onto the Bitcoin network ourselves. We form something that should be valid and feed it to Core, letting Core once again do the heavy lifting. If the Tx goes through, cool. If not, we try to give info to the user explaining what might have gone wrong.

Like I said, I could be wrong about some of the details. I'm pretty sure this is correct, though. It just doesn't make sense to, say, take several hours to download the blockchain (including time to verify the blocks) and then take several more re-validating everything. We trust that Core will provide us with good data. This has led to certain issues, like when the blockchain isn't complete. (Core apparently validates a block and then attempts to write it to a file. If the write fails, Core won't care. Obviously, this leads to weirdness with Armory.)

I haven't tested it personally. I think a user tried it with a pre-0.11A version and said it worked fine.

As I understand things, Armory shouldn't have any problems if it encounters bigger blocks. If there are bugs, fixing them should be pretty trivial. Core/XT does the actual block validation. Armory then runs with the ball and is more concerned with the block's transactions, which aren't affected by the blocksize debate.

(If I'm wrong about any of this, I'm sure other developers will correct me. )

I'm not aware of any such plans at the moment. That said, we are working on a setup that should make it easier to support multiple offline bundles. No promises but hopefully the stuff we're working on will make bundle support much easier.

AFAIK, this wouldn't work, at least not with the way Armory's set up. You could store and/or read the data on a networked drive but that's it.

Hello. Is thread 0 the one that actually crashed? It could be a different one. The crash report will always say which one it is.

IIRC, all pre-0.90 versions didn't use a DB. Instead, they tried to load the entire blockchain into memory. So, 0.87.2 is going to try to load something like 50 GB of data into RAM. I'd imagine this isn't feasible on your system.

AFAIK, you're best off just upgrading to the latest Armory (0.93.2) on both your online and offline systems. You shouldn't have any problems loading your wallets, although the online system will need some time to build the DB. No matter what, be sure to back up your wallets, either in paper or digital form.

There are two command line options. Use the "--datadir" option to change the Armory home directory (not that big a deal once 0.94 is released), and the "--satoshi-datadir" option to change the Bitcoin home directory (much more important since you'll still need a full blockchain).

I use Armory on my Mac often and very rarely see crashes. I've heard some people are still having performance issues. My theory is that Qt (an underlying library) just doesn't play nice with some Macs due to threading issues. I've been trying to make some noise and get this investigated. If anybody would like to help me out, please upvote this bug. The patch I posted there doesn't fix everything but it does fix a lot of issues. Maybe drawing more attention to it will lead to more long-term fixes.

*jumps off soapbox* Anyway, regarding this crash, if it happens again, look for the following bits of info.


The crashed thread will test you which trace to post, which is the gobbledygook at the bottom of my quote. I'm guessing it'll be a Qt issue but I could be wrong.

Also, just curious, do you put your Mac to sleep often? I do get the odd crash on Yosemite after I've put my Mac to sleep something like 12-15 times, along with other odd behavior. Some of it might be Armory - I'm investigating right now - and some of it is almost certainly Qt (or Yosemite causing Qt to freak out).