Ack!  That's an error I haven't seen yet.  Can you try starting Armory again but using the "--rebuild" flag.  Sounds like the database somehow got corrupted.  So far, I have seen it safely recover from being restarted while building the database, but it may not be reliable -- it looks like your system may have interrupted the initial database build (since it says 65k raw blocks added, not 260k blocks). 

Obviously it should be robust, but those are things that will take some time to iron out.  Until then, can you simply wait through another --rebuild and let me know if you get the same problem?  People have actually tested it on 12.04 with 2GB of RAM, so I know it's possible to work

Hey guys, sorry for the lack of updates recently.  I am still trying to get my brain back on track now that my in-laws have left  So I haven't had a chance to fix any of the startup bugs, but goatpig did make me a nice script for fixing the build issues.  It has been tested on a couple versions of Linux and seems to work great.  

Basically, it's a script that is run as part of the makefile, which attempts to locate the correct libpython dependencies and writes the correct values to a pypaths.txt file.  That file is then included in the Makefile.  I mention those details, because if it doesn't work, you'll probably have to manually set the paths in pypaths.txt, and then comment out the line in the Makefile (near the top) that executes the "whereispy.sh" script.  But hopefully no one will have to do that

If you are a linux user, especially one that had compile issues with 0.89.99.5, please try it again.  Checkout a fresh copy and try building.   The last build issue to be resolved on Linux is a redefinition error in log.h, where two functions appear to be the same when compiled on 32-bit systems.  I just have to find the right preprocessor for it and that should be resolved, too.  

So if you are on 64-bit Linux, the new Makefile should work, on all versions of Ubuntu, and I think goatpig tested Fedora, too.  If you are on 32-bit linux, you might have to comment out three "redefined" functions in log.h, but then it should compile fine.  

Actually, that sounds like a bug.   Regardless of size/dust, Armory should show you the correct balance.   I'm not sure how I would debug this though.   Does Armory show you the correct block number in the  bottom right corner?

Consider a government that is trying to reduce the privacy of the network as a whole.  They have observed 10,000 different transactions.  Of those 10,000, they know some of them are drug deals, some are suspected money laundering, some are political contributions, and some of them are withdrawals or deposits made to exchanges accounts for which they know the identities.  The point is, they know the identities of a few points on this web of 10k transactions, and they know the nature of some of the other transcations, but they are working with a very incomplete set of information.  

Let's say you execute both tx A (a deposit to a coinbase account), and tx B (an "anonymous" political donation).   The government knows that you are responsible for tx A, since Coinbase had to follow AML/KYC rules and has your identity.  Or tx A was a purchase you made on some website where the government saw that you purchased some alpaca socks for 1 BTC (a lot of socks).  But since you never re-use addresses, they don't know that tx B was executed by you, they only know that the address is a donation address that has received multiple donations.

But now the entity/gov't dust-spams all the input addresses of all these transactions.  There's a chance, on your next transaction, that your wallet will try to clean up the dust, and put all of it into a single transaction to aggregate it.  However, by doing so, it is including dust from input addresses from tx A and input addresses from tx B, which makes it immediately obvious that both addresses are owned by the same person, and thus the same person who owns the coinbase account also was the payer of tx B.  They have now linked together identities that were not otherwise linked.  And it was totally unknown to you, because the wallet needs to handle dust, change and coin-selection totally transparently to the user.

It doesn't have to be a government.  There are other ways this can be used to compromise privacy.  In all instances, it has to do with the dust spam being "cleaned up" by the wallet, and leaking information in form of linking addresses that otherwise would not have been linked.  Theoretically, a critical mass of CoinJoin transactions will reduce the strength of those linkages, but it probably it will still "suggest" linkages that might otherwise not have been made.

Expert users who understand this might want the ability to blacklist dust that is of unknown origin.  The wallet might even do this automatically, if it has a reliable set of rules to follow.  For instance, Armory only bundles in extra dust if doing so wouldn't reduce the privacy of a transaction. But sometimes it's unavoidable to include that dust:  say you sweep your wallet to a new wallet/address.  And you can't even dump all the dust without linking all the dust addresses together. Given that they are worth effectively nothing, the best thing to do might be to ignore/blacklist it.

Of course, we'd like it if the dust didn't just atrophy the network.  But for the super-paranoid folks, there may be no other option.

That's a tough one.  Given that coin-control is already implemented, there may be a way to do it... but coin-control only controls addresses, not individual outputs.  So it may require some modification to do this.  It's definitely not on the priority list, but it's a defensive measure that makes sense to implement for the paranoid folks

I'll think about how to do it, and we're going to put a note in our SW system to remind us to eventually do that.  Definitely an expert feature though, and we have tons of other critical things that need to be addressed right now.  But I want to do it.  Eventually.

Try the new version:

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

It is a testing version, so it has the usual caveats about being less reliable, but it's been in testing for a while, and no one has reported any issues other than the occasional crashing or having to rescan.  It works well for a lot.

It will take a couple hours on the first load to build the database, but after that it should take 30-90 seconds.  And it literally uses 1/20th the amount of RAM, so it should work even on a system with 1-2 GB.   You can use it to move your coins out, or use it to hold you over until the official release which will be much more usable than 0.88.1.

Definitely a bug.  Send me your log file! 

support@bitcoinarmory.com

For reference, there is nothing special about change addresses.  To the network, they look like any other addresses, and everything should work identically.  However, given some abnormal behavior, like buttons or windows not behaving properly, there's most definitely some errors getting triggered and waiting for me in that log file! 

We will eventually have something that works on the Android platform.  Until then, it's not going to work.  But it is a natural fit:  I was able to get the Craig 10" Chromebook, CLP281 for $40!  I haven't seen a deal that good since then, but it looks like you can still get one for $80-$100.  That might end up being cheaper than a HW wallet too (Trezor, BitSafe).  More flexibility, but not quite as convenient.

Btw, I'm not currently using it:  I impulse purchased it assuming I could wipe it and put linux on it, but it turned out to be a royal PITA to do that.  Instead, I'll just have to use its presence in my house as motivation to work on the Android app

Ironically, I just had this same "problem".  Except that the transaction does not get entirely deleted... it just gets renamed to *.SENT.tx.  It's still there... but you have to select "All Files".  I should've made that more obvious somehow...

It's on the to do list.   Need the new wallets first, but gotta finish RAM reduction before that.  Luckily, there's a lot of new capability I can implement with the new wallets, since that will also include BIP32, and so I'm placing it high on my priority list.   

Be patient :-)  it's coming.

Make sure you have installed all the packages listed here:

http://bitcoinarmory.com/download/building-armory-from-source/

And then make sure you switch to the "testing" branch, not "ramreduceleveldb".  The only other thing you might need to do is modify the BitcoinArmory/cppForSwig/Makefile, but I think I have a fix for that soon (thanks Goatpig!).  Today I'll try integrating & testing it, and push it to the testing branch.

What OS are you in?  32-bit or 64-bit?

By the way, you don't need the leveldb or snappy packages.  Everything you need (wrt LevelDB) is included in the project.

"cd BitcoinArmory; make" is mostly equivalent to "cd BitcoinArmory/cppForSwig; make swig".  Both should do the same thing. 

There is no problem using the new/testing version to create transactions to be signed offline and then broadcast.  The nice thing about the offline system is that you can always keep an old, stable version on there, and it will notice if something is wrong.  For instance, if online Armory does not construct the addresses properly, the offline system will throw an error, or display a different address than you were expecting. 

The online-offline split provides an extra layer of protection against both malicious attacks, and bugs!   But so far I've used it for multiple online and offline transactions, and I have other people helping test with no reports of issues beyond the usability ones.  If you're really paranoid, just make sure you read the confirmation dialogs closely and verify the addresses match.  Those dialogs haven't changed at all, so they are reliable at reporting what is actually in the transaction you are about to execute.

Thanks for identifying how much more work I have to do to get this version stable

It's tough getting my brain back into the game after 2-3 weeks of vacation!

Try starting it with " --skip-online-check".  Are you behind a proxy?

 
I don't know if this is the problem, but you can run it with "--rebuild" which will delete the database and start over from scratch (Bitcoin-Qt DB will still be there, so it will only take 1-2 hours to do a rebuild).  I'm curious if doing a full rebuild fixes it for you.  So far, I haven't seen any one need it yet, but if you have no other choice, you should try it.


It's safe to use for executing offline transactions.  I'm just not 100% confident that the backups will be the same as the final version.  I know it creates a frustrating dynamic, because I need people to help test the backups, but I have to tell them not to rely on them yet.

A frustrating anecdote:  the Crypto++ library does not wrap around values greater than N (and it rightfully shouldn't).  Instead, it just segfaults.  I know this because in testing address importing, I frequently use strings like "\xaa"*32 for the private keys.  One day I used "\xff'*32 without realizing I was picking an invalid private key, which led to like a full day of tracking down this devastating "bug" which was really just developer stupidity. 

In practice, if your "random number generator" leads to a private key that is out of range, it's more likely a bad RNG or a malicious result than it is that you just got "unlucky".  With even a mediocre RNG, this isn't an issue.

There is no limit.  The paper backup produces an essentially infinite chain of addresses.  The solar system will collapse on itself before you could generate enough addresses to risk generating the same private keys as anyone else.  

Go ahead and use a quintillion addresses (if you have time to generate that many).  You are at no risk of collisions.  And all will be protected with the paper backup.

All transactions have inputs (TxIns) and outputs (TxOuts). 

The TxOuts are where the coins are going, identified by the TxOut script (which is the "puzzle" I was speaking about). 

In order to spend coins that you "own", you create a transaction and make one TxIn for each TxOut you want to spend.  So the new transaction references a bunch of TxOuts from previous transactions in the global history.  The TxIn simultaneously identifies what TxOuts you are spending and supplies the data to prove that you are authorized to spend them (public key and a signature over the entire transaction).

The TxOut script is the "puzzle" that needs to be solved, and your wallet app tells you that you "own" coins because it has identified that it knows how to spend them.  When you do spend them, you put your sig and pubkey into a TxIn script, and those will be on the stack when the TxOut script is executed.

Let me reiterate:  each TxIn corresponds to a single previous-TxOut being spent.  And that TxOut is fully spent and not needed anymore (this would be pruning:  right now all nodes remember all TxOuts, even the ones that are already spent, but you really only need to remember/store the TxOuts that haven't been spent).  Therefore, a transaction "eats" a certain number of TxOuts, and then creates a bunch of new TxOuts that can later be spent the same way.