Regardless of how I wrote it, it's been in use for 2 years with only one address type.  All testing and evaluation has been done with the single type that was in use.  Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code." 

The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money.  Anything else would be reckless, no matter how the original code was written.

The simplicity is over-stated.  The concept is simple and can be represented in 5 lines of code.  But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address.   These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.

The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins.  Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.

For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts. 

Oh, I didn't even look at the log file before responding.  It looks like maybe there's some kind of interactive message that is blocking on the gconftool command (which is used for setting up Armory as your default URI handler).  I wonder if that's it.

Can you open a terminal and run the following command and tell me what it spits out?

Starting a company and overhauling the blockchain engine has pretty much destroyed all the other priorities.  But both those operations are rapidly nearing completion and I'll be able to get back to the wallet development.  I'm looking forward to it as much as others are

You're not going to be able to open it in a regular editor... it's a multi-gigabyte file.  vim should work, but it's a bear to use unless you know what you're doing.  Really though, we'll get a script for you that will do it automatically.  Just hold tight   (and pester me if you don't hear back)

Sorry, what I meant was:  we open the disk files as raw binary files and search them for unique strings that only appear in Armory wallets.  If the wallet still exists anywhere on the VM (even as a deleted file), a raw binary search will find it.

Oh, that's probably even worse than deleting it, since you can usually forensically recover a deleted file.  I bet the restore is dramatically complicated.  However, I suppose it's possible to still recover something...

Turn off your virtual machine, and locate the directory that contains the hard disk.  We should probably just scan all related files, including the hard-disk file itself.  I will forward this to CircusPeanut who should be able to write a quick script that will search a directory, open all files in binary mode, and do a raw search for a bunch of magic strings that appear in wallet files.  With some luck, the virtual-disk interface works like a real HDD, where "deleted" files may not have been actually deleted but ignored, to be overwritten when something else needs the space.   A raw binary search should tell us right away if there's anything on that disk that even resembles a wallet.

Much more extreme would be a similar raw search of your host (physical) drive.  That's a bit more challenging and a bit more work.  I guess it depends how much BTC you had in there.  Wonder if the cost-to-benefit is there.

What OS are you in?  CircusPeanut should be able to write a dependency-less python script that will search for unique patterns that appear in Armory wallet files.  But if you're in Windows you'll have to install python for that to work.  For CircusPeanut or anyone else that would like to take a stab at raw binary searches for wallets, you can probably search for \xBAWALLET\x00 which will appear as the first eight bytes of any wallet file.  After that, you can look four bytes later for the network magic bytes \xF9\xBE\xB4\xD9.  Once you have that, you can use the binary map I linked above to figure out how much data to copy.

You might be alright.  Just because the machine crashes doesn't mean that the virtual disk drive is lost.  Very frequently, you can still access that drive (i.e. make a new VM and add the VM disk of the old one to it).   As long as you didn't restore to before the wallet was made -- any version of the wallet is fine for recovering all the coins.  If you restored to before that point in time, you would probably be SoL. 

If you can get access to the wallet file in any way, then you can copy it out and import it into another instance of Armory.  Let me know how it goes.

Run it with --debug to get more output

This is not an Armory thing, this is a Bitcoin-network-thing.  The 0.0001 fee is actually a "relay-only" fee, which doesnt' guarantee it will be mined, only that the network will see it.  Right now, that's usually sufficient to get it mined, but my goal is to minimize issues, and using the 0.0001 minimum fee is likely to result in tx occasionally getting stuck (maybe not right now, but possibly in the future).  

Any tx with any outputs less than 0.01 BTC must have a fee of 0.0005 for the default client to mine it (0.0001 to relay).  There is no way around it unless you have a generous miner.  And a recent soft network rule went into effect that makes outputs less than 0.00005430 (I think) not even standard.  The network discourages tiny payments, though "tiny" is a moving target with the rising bitcoin price.

The real issue being brought up by kjj is simply that you may not be getting full entropy out of the rolling if there's any subjectivity involved.  However, even if you aren't rolling dice properly, you are still getting entropy, just not full entropy.  Consider that you roll a die 32 times, and you don't properly re-roll it and you get the exact same number as the last roll half the tie.  Well, then you got 16 dice-rolls-worth of entropy instead of 32.  Not ideal, but you're still producing nice analog entropy -- just not as much as you thought.

For this reason, if you use something like dice rolls, coin flips, etc.  I recommend you do maybe 2-3x the number of rolls/flips than you are really looking for.  Especially because this operation is done so infrequently, a little patience up front is worth it to have the extra confidence. 

Hashing the result is sufficient, though the FIPS method sounds good too, where F is the order of the secp256k1 group, which is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 (bigendian)

The best bet is to uninstall and reinstall 0.88.1 from the website.  Then run it in offline mode and pull your private keys out like IntrepidMiner recommended.  Import them into another wallet.  Right now it sounds like there's too many problems with the new version.

Though if you have a log file for me, I'd love to see it. IT would be in C:\Users\<user>\AppData\Roaming\Armory.  Anything with "log" in the name you can email to support@bitcoinarmory.com.

Sorry you're having such difficulty...

Okay, I just ran into a problem on windows that wheeler originally observed.   Luckily, this one is isolated, so I should be able to catch it easily.  It causes the "cannot get tx copy" message.  I thought it was a DB-corruption issue, but instead it looks like it has to do with orphan blocks in the block files under certain conditions. 

For me, it keeps triggering at the same block, so I should have no problem isolating it.

One day, this stuff will work...

Is this the .dmg/app that was downloaded from our website?  Or did you follow Red Emerald's instructions to build it yourself?  Because that's clearly referencing system libraries, which I'm pretty sure the .dmg is not supposed to do (it's supposed to be totally isolated).  Perhaps that's a hint for why it doesn't work on some systems?

I have some stuff from picobit to try, which may improve the OSX compatibility.  But I'm still getting caught up with some other things.  Maybe someone else wants to try what he produced and give me a review?   My new Mac Mini isn't sufficiently setup to try it yet.

@pvz and @wheeler:

I just ran into the segfault issue when using --rebuild.  It turns out that i screwed up some pointer cleanup, and that was causing the segfaults.  Luckily, the last update was so tiny that it was obvious what did it!  I just fixed it and committed it.  Please do a "git pull origin testing" and then try the --rebuild again.

It might also have been responsible for the other issues you observed, though I won't be sure until you try it. 

Ack, this is really not going well on Ubuntu 32-bit (that's what you're in, right?).  You can remove the /home/xxx/.armory/databases directory to retry from scratch.  Though, "--rebuild" should do exactly that.

I noticed the line "pthread lock:  Ongeldig argument", I assume that means "Invalid Argument"?  If so, that may be the source of the problem, perhaps the way leveldb is being compiled here is not playing nicely with the 32-bit libraries.

Are you running a 32-bit OS?  I just committed the first version that should build on 32-bit *nix, but haven't had much chance to test online mode (only tested offline mode).  pvz appears to be in 32-bit as well, and I wonder if that's related...

It is.  The default behavior is to rebuild if the DB doesn't exist.  Just like I mentioned in that other thread, it looks like you might've interrupted the DB build process in the middle and then it restarted (hence only 77k blocks processed, not 260k).  It's worked on my system before but it may not be reliable yet (to interrupt and then restart the build).

This looks eerily similar to teh guy that just posted here:

https://bitcointalk.org/index.php?topic=316312.0

I wonder if the recent update did something... because so far I haven't ever seen that error until I committed the tiny update a couple hours ago... at least it should be easy to track down what happened...

Can you please try --rebuild.  It will take a while to rebuild the database, but it sounds like your DB is corrupted.  There's some transactions in the DB that were only partially written.  That's bad.

Oh this is fun (for you C++ Linux devs)!  I didn't know this existed:


That prints a full list of all pre-processor symbols defined by default in your g++ compiler.  I noticed a bunch of things I didn't know were normally compiler defined.  Just some samples from my system (Linux Mint 15, 64-bit):