Armory - Discussion Thread

[etotheipi]

does Armory work with Ubuntu 12.04?  having trouble installing...

I installed it without issues on a 12.04 fresh install so you should be able to use it too.

etotheipi, I figured why those bitcoind connection problems happened.
I had the number of connections limited on bitcoin.conf(maxconnections=30)
After removing that line from bitcoin.conf never again I had connection problems between Armory and Bitcoin-Qt

Awesome!  Good to know!  I bet that explains a lot... since I connect as a regular peer, I guess the localhost (Armory) can get dropped if you are at max connections.

I'll keep that nugget of information around for folks who are having network issues.

[salfter]

I've gotten Armory working with the Gentoo Linux LiveDVD.  Instructions are posted here.

[etotheipi]

I've gotten Armory working with the Gentoo Linux LiveDVD.  Instructions are posted here.

Great!   I bet there's a lot of folks who will like this.  I guess I should just warn folks, that Gentoo can be a bit daunting.  I used it once -- "emerge" was great, but everything else was rather difficult.  I'm sure there's plenty of users out there who are comfortable enough with linux for this, I just wanted to put the warning out there. 

Thanks for doing this.  I'll have to update the original post with an index to side-projects such as these.  I love seeing people expand on my work! 

[cypherdoc]

does Armory work with Ubuntu 12.04?  having trouble installing...

I installed it without issues on a 12.04 fresh install so you should be able to use it too.

etotheipi, I figured why those bitcoind connection problems happened.
I had the number of connections limited on bitcoin.conf(maxconnections=30)
After removing that line from bitcoin.conf never again I had connection problems between Armory and Bitcoin-Qt

64 bit?

[Raoul Duke]

does Armory work with Ubuntu 12.04?  having trouble installing...

I installed it without issues on a 12.04 fresh install so you should be able to use it too.

etotheipi, I figured why those bitcoind connection problems happened.
I had the number of connections limited on bitcoin.conf(maxconnections=30)
After removing that line from bitcoin.conf never again I had connection problems between Armory and Bitcoin-Qt

64 bit?

Yes, 64bit.

[etotheipi]

64 bit?

Download from the 64-bit version from the downloads page:  https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-1_amd64.deb
 
The package should replace itself correctly, but let's assume it didn't.  Go to the command-line and type the following.  First line removes any existing Armory installation, second one tries to reinstall it:

Code:

sudo dpkg -r armory
sudo dpkg -i armory_0.82.4-1_amd64.deb

If that gives errors about unmet dependencies, then you need to install them.  Luckily, Ubuntu remembers what you were missing when you last tried to install such a package, so I believe you only need to type the following:

Code:

sudo apt-get install --fix-missing
sudo dpkg -i armory_0.82.4-1_amd64.deb

Finally, if that still doesn't work, then explicitly install all the packages you need and try again (found on the Building Armory from Source page):

Code:

sudo apt-get install git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted
sudo dpkg -i armory_0.82.4-1_amd64.deb

If that still doesn't work... well I'll reset my Ubuntu 12.04 VM and see if can walk through it from fresh install and try to replicate any issues.  Until then, I think this should work.

[fabrizziop]

64 bit?

Download from the 64-bit version from the downloads page:  https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-1_amd64.deb
 
The package should replace itself correctly, but let's assume it didn't.  Go to the command-line and type the following.  First line removes any existing Armory installation, second one tries to reinstall it:

Code:

sudo dpkg -r armory
sudo dpkg -i armory_0.82.4-1_amd64.deb

If that gives errors about unmet dependencies, then you need to install them.  Luckily, Ubuntu remembers what you were missing when you last tried to install such a package, so I believe you only need to type the following:

Code:

sudo apt-get install --fix-missing
sudo dpkg -i armory_0.82.4-1_amd64.deb

Finally, if that still doesn't work, then explicitly install all the packages you need and try again (found on the Building Armory from Source page):

Code:

sudo apt-get install git-core build-essential pyqt4-dev-tools swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted
sudo dpkg -i armory_0.82.4-1_amd64.deb

If that still doesn't work... well I'll reset my Ubuntu 12.04 VM and see if can walk through it from fresh install and try to replicate any issues.  Until then, I think this should work.

I think I installed it using sudo apt-get -f install for the dependencies.

[da2ce7]

Hello etotheipi

I'm one of the developers of Open Transactions;  I am primarily an C++ Windows developer.

I have been looking at your siwg interface and native code, and I think that I will try and clean it up a bit for windows at-least.

You may want to see how we have managed our Open Transactions swig interface:

https://github.com/da2ce7/Open-Transactions/tree/master/swig

I'm thinking about doing something similar for Armory... hmm.

[MysteryMiner]

1. What source of entropy Armory uses for initial wallet seeding? - I can answer myself looking at code but for someone who knows answering this will take only seconds.

2. Does keys generated by deterministic wallet that Armory can be linked to each other using known or potential crypto?

3. Original Satoshi client generated new address when receiving new transaction before QT fucked it all up. In paper it is stated that it is recommended that each address is used only once to prevent person linking and use of statistical analysis. Can Armory generate new receiving address when new transaction is received with current address selected?

4. Is there any minimum requirements for underlying Bitcoin client? Can current version run with Bitcoin 0.3.xx version?

[etotheipi]

1. What source of entropy Armory uses for initial wallet seeding? - I can answer myself looking at code but for someone who knows answering this will take only seconds.

Armory uses the Crypto++ library, which handles all the entropy operations.  I remember once seeing a list of entropy sources used by Crypto++ but I can't find it now.  All that matters is that it "is suitable for cryptographic purposes"  (it is a standard crypto library, though it's kind of slow).

2. Does keys generated by deterministic wallet that Armory can be linked to each other using known or potential crypto?

Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets.  Without access to at least the watching-only wallet,  there is no way for anyone to associate two addresses or public keys.  The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key. 

3. Original Satoshi client generated new address when receiving new transaction before QT fucked it all up. In paper it is stated that it is recommended that each address is used only once to prevent person linking and use of statistical analysis. Can Armory generate new receiving address when new transaction is received with current address selected?

I don't know exactly what you mean... but Armory will generate a new address for you every time you click "Receive Bitcoins", and also when it needs to send change to itself.  I recently started flagging addresses in the wallet properties that were created solely for change.  Some people had asked about how to tell the difference, and there really wasn't a way.  Now all change addresses are marked with "[[Change Received]]", and you can sort by comment field to look through change addresses or non-change addresses (it's not the most useful thing to do, but you can do it).

4. Is there any minimum requirements for underlying Bitcoin client? Can current version run with Bitcoin 0.3.xx version?

Armory implements a very minimal part of the networking protocol.  As long as the Bitcoin-Qt client version has the Feb15 protocol upgrade, it will work (which I believe was added in version 0.3.XX.

[MysteryMiner]

I recently started flagging addresses in the wallet properties that were created solely for change.

Hidden by default with checkbox to show/hide could be nice!

Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets.  Without access to at least the watching-only wallet,  there is no way for anyone to associate two addresses or public keys.  The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key.

If generated address is not dependent on previously generated address in any way than it might be OK. Many so called "attacks" against crypto algorithms require related keys. Not a math expert myself I don't know if this is applicable to Armory generated address. But the blockchain transactions might be somewhat compromised if the addresses can be linked using this method. Basically then You cannot then just say "sorry officer, I sold all those Bitcoins I purchased from my MtGox account to someone else I don't personally know. I did not know he will be ordering drugs from you straight away!"

The solution might be a non-deterministic wallet possibility. It might be available under "Advanced" options where currently crypto options are located with appropriate warnings that paper backup is not possible with such type of wallets. The deterministic type must be the default type of wallet because users who use Armory over other clients and front-ends are probably because they need the deterministic property and paper backup functionality.

And Thank You for creating Armory! It is a great job, it functions well enough and offline wallets and offline signing are easy to use and probably only way to not lose precious Bitcoins to hacking.

[kjj]

I recently started flagging addresses in the wallet properties that were created solely for change.

Hidden by default with checkbox to show/hide could be nice!

Addresses cannot be linked unless you know the chaincode, which is stored in both full wallets and watching-only wallets.  Without access to at least the watching-only wallet,  there is no way for anyone to associate two addresses or public keys.  The strength of this non-linkage is as strong as the inability for someone to derive your private key from your public key.

If generated address is not dependent on previously generated address in any way than it might be OK. Many so called "attacks" against crypto algorithms require related keys. Not a math expert myself I don't know if this is applicable to Armory generated address. But the blockchain transactions might be somewhat compromised if the addresses can be linked using this method. Basically then You cannot then just say "sorry officer, I sold all those Bitcoins I purchased from my MtGox account to someone else I don't personally know. I did not know he will be ordering drugs from you straight away!"

The solution might be a non-deterministic wallet possibility. It might be available under "Advanced" options where currently crypto options are located with appropriate warnings that paper backup is not possible with such type of wallets. The deterministic type must be the default type of wallet because users who use Armory over other clients and front-ends are probably because they need the deterministic property and paper backup functionality.

And Thank You for creating Armory! It is a great job, it functions well enough and offline wallets and offline signing are easy to use and probably only way to not lose precious Bitcoins to hacking.

The EC math used to generate the keys is pretty much the same as the EC math used to perform the digital signatures in transactions.  As in, if you can run the key sequence backwards and find the root key, you probably don't need to.

[MysteryMiner]

According to this topic https://bitcointalk.org/index.php?topic=114701.0 the sharing of private key from deterministic wallet is bad. As I understand the attacker need to know both private key AND the chaincode to calculate and steal all other possible keys, right? The chaincode is kept on computer and as long as the computer security is not compromised the chaincode remains secret.

[etotheipi]

According to this topic https://bitcointalk.org/index.php?topic=114701.0 the sharing of private key from deterministic wallet is bad. As I understand the attacker need to know both private key AND the chaincode to calculate and steal all other possible keys, right? The chaincode is kept on computer and as long as the computer security is not compromised the chaincode remains secret.

First private key + chaincode = compromise of all private keys (security fail)
First public key + chaincode = reveal all public keys/address (privacy fail)

The chaincode by itself is not useful.  Even if someone gets the chaincode, they still need your first public key in order to derive the rest of your public keys (your first Bitcoin address is not enough).

And even if someone got your first one million public keys, they wouldn't be able to deduce the chaincode.  The same goes for private keys:  if someone has the first N public or private keys, they won't be able to compute public or private key N+1 without the chaincode.

People should not be sharing private keys from their Armory wallets.  Or really, any wallet, except under bizarre/experimental circumstances.  They're called "private" for a reason.

[inglian]

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

I finally had to use command line bitcoind sendrawtransaction on the full tx hexcode in the log. Would be nice if the "Copy Raw Tx" button included the signature.

Thanks for creating Armory; small tip included in tx 4e347493f888f21d2f4163171c5ec20bc7c965df0aba83934e7880e9e5c829c2

Using Armory 0.82.2 on Win7-64 with Bitcoin-qt 0.7.1.

Code:

2012-10-28 22:22 (ERROR) -- armoryengine.pyc:479 - Traceback (most recent call last):
  File "qtdialogs.pyc", line 6122, in broadTx
  File "ArmoryQt.py", line 1896, in broadcastTransaction
  File "armoryengine.pyc", line 9154, in sendTx
ConnectionError: Connection to localhost DNE.

[etotheipi]

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

I finally had to use command line bitcoind sendrawtransaction on the full tx hexcode in the log. Would be nice if the "Copy Raw Tx" button included the signature.

Thanks for creating Armory; small tip included in tx 4e347493f888f21d2f4163171c5ec20bc7c965df0aba83934e7880e9e5c829c2

Using Armory 0.82.2 on Win7-64 with Bitcoin-qt 0.7.1.

Code:

2012-10-28 22:22 (ERROR) -- armoryengine.pyc:479 - Traceback (most recent call last):
  File "qtdialogs.pyc", line 6122, in broadTx
  File "ArmoryQt.py", line 1896, in broadcastTransaction
  File "armoryengine.pyc", line 9154, in sendTx
ConnectionError: Connection to localhost DNE.

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

[Raoul Duke]

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

I finally had to use command line bitcoind sendrawtransaction on the full tx hexcode in the log. Would be nice if the "Copy Raw Tx" button included the signature.

Thanks for creating Armory; small tip included in tx 4e347493f888f21d2f4163171c5ec20bc7c965df0aba83934e7880e9e5c829c2

Using Armory 0.82.2 on Win7-64 with Bitcoin-qt 0.7.1.

Code:

2012-10-28 22:22 (ERROR) -- armoryengine.pyc:479 - Traceback (most recent call last):
  File "qtdialogs.pyc", line 6122, in broadTx
  File "ArmoryQt.py", line 1896, in broadcastTransaction
  File "armoryengine.pyc", line 9154, in sendTx
ConnectionError: Connection to localhost DNE.

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

inglian, are your network connections limited on bitcoin.conf? If so, take out the limit.
I faced similar problems when I had the number of connections limited to 25, so Armory would only connect to the bitcoin client when one of the regular network clients dropped it's connection.

[etotheipi]

Back from Armory vacation!

The last month has been devoted to lots of random things, the biggest of which is wedding planning.  I also got distracted by some random side projects and even a couple games.  However, it was a much needed break after an epic battle to make Armory multi-threaded -- I hit a frustrating combination of threads losing synchronization causing difficult-to-debug seg faults, etc.  I spent days debugging, and I was desperate to be distracted by something else... so I found other things...

However, I jumped back in recently feeling refreshed, and without any other distractions (plus, a few days off of work due to Hurricane Sandy gives me some time to dig in).  After a rough re-entry battle, I found a single bug that seemed to clear up almost everything.  There's still some features remaining to be implemented for the GUI to play nice with asynchronous BlockDataManager.  But most of it is working.  I even had it running for two days without any issue -- I didn't actually send any coins in that time, but at least there are no memory leaks or issues with reorgs, etc.

Additionally (and importantly), I optimized some of the blockchain scanning code, so now mega wallets (with 1000+ addresses) should operate much more fluidly.  The fix seemed too easy, and I seem to remember there was a reason I didn't do this 4 months ago... but so far I can't see anything wrong with it.  Testing will be key.

So, I don't have an official testing release yet, but maybe ambitious folks like Red Emerald would be inspired to check out the "threading" branch and try it  It'll throw a few errors for some operations (like shutting down), but it won't lose you any money -- the worst that can happen is the GUI loses communication with the BlockDataManager and then you can't view balances, etc (but I haven't seen that happen recently).  If you do test it:  please open the latest stable version first (0.82.4) and write down your wallet balances, to compare to the balances reported by the new version.  I want to make sure wallet scanning is still reliable.  

When multi-threaded Armory is stable, that will be beta!  0.82.4 has been working very reliably, and this new version (0.84) will be tremendously more usable, now that it opens immediately and tells you what's going on (scanning, offline, disconnected, why it can't go online, what you can do in each mode, etc).  Hopefully, it will be no more than a couple weeks!


EDIT:  As I should've expected... I broke a lot more things than I thought I did.  It seems that all import/sweep operations only update the wallet balances after a restart  (probably related to the scanning code I updated).   So I still have plenty of work to do here...

Red Emerald:  I called you out specifically, because I think you had tried this version before, and found it unusable -- I discovered the exact same thing when someone sent me a wallet with 1000 addresses with 1000+ transactions.  The scan operation was running in O(N²logN) instead of O(N logN), causing the GUI to timeout while waiting for updates from the BDM.  This was only noticeable when you have tons of addresses (which is why I didn't see it at first, but then ran into it after someone sent me a huge wallet)

[inglian]

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

I installed https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-alpha_win32_and_win64.msi which runs for a few seconds and then silently dies without logging anything. Same immediately after a reboot with bitcoin-qt running and up to date on blockchain. Any troubleshooting I should do?

inglian, are your network connections limited on bitcoin.conf? If so, take out the limit.
I faced similar problems when I had the number of connections limited to 25, so Armory would only connect to the bitcoin client when one of the regular network clients dropped it's connection.

Connections are default (125), though with NAT I have none incoming and just my default 8 outgoing. So I should be able to accept another 117 connections locally.

Thanks to you both for the help.

[etotheipi]

My first attempt at broadcasting an offline transaction with Armory kept silently failing. Logs show "ConnectionError: Connection to localhost DNE" despite Armory showing "Connected" status on the main screen and current block number.

This problem has come up quite a few times in the past, but it was so long ago I honestly don't remember if it was ever resolved.  However, there have been some networking-related bug fixes since then.  Please download 0.82.4 and try again:  https://github.com/etotheipi/BitcoinArmory/downloads

I installed https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-alpha_win32_and_win64.msi which runs for a few seconds and then silently dies without logging anything. Same immediately after a reboot with bitcoin-qt running and up to date on blockchain. Any troubleshooting I should do?

Odd... can you create a new shortcut for it and run it with the " --debug" flag?  That might reveal a little more information.  Unfortunately, it sounds like a seg-fault...