Armory - Discussion Thread

[K1773R]

Someone just asked me about how to run Armory over Tor.  I realized that not only do I have no idea,  but I've heard users claim they have done it,  and I never paid attention.  Can someone please explain how to do it?  I will add the description to the webpage once I see a consensus.

I managed to get armory to connect to bitcoin-QT while on Tor by changing the default listening address in tor to 8333*, then simply running bitcoin-QT and Armory as usual.  I believe the command --listenaddress** allows you to change the default listening address to 9050 so it will work with the normal Tor/bitcoin-QT settup, but I never got this to work.

*Is this the right default SOCKS address for bitcoin-QT?
**I'm not sure this is the right startup command can you confirm/correct this etotheipi?

Hope this helps.   I typed in a hurry so if detail are missing let me know.

Port 8333 is the default listening port for Bitcoin-Qt.   I am not familiar with proxies at all, and never really used any custom CLI options with Bitcoin-Qt.  So I can't really comment any further on this.  But if someone can give me a short list of what needs to be done to get Bitcoin-Qt-already-connected-to-tor, to play nice with Armory, I'll happily post it on my website.

Also, Armory does a version check when it first opens, which can be disabled by going to "Help-->Armory Version..." and clicking "Never check for new versions".  Someone complained about that.  There's also an "online check" to determine if the user has an internet connection -- basically it just checks for google.com.  That can be disabled via --skip-online-check on the CLI.

I used to run bitcoin through tor as a hidden service.  I'll experiment more and write up some nice steps.  However, it should be really simple and nothing should really need to be done to armory since it uses bitcoind for all of it's networking anyway.

The proper way to get bitcoin to use tor is to add "proxy=localhost:9050" (assuming tor is listening locally on the default port) to bitcoin.conf.  No need to mess with tor's listen address.  You will also need "listen=1" so it will be able to communicate locally with armory.

When I had a tor hidden service running, I also had "discover=1" and "externalip=mylongstringofgibberish.onion"  I'm not sure if those options will need tweaking for Armory.

Then start armory with "--skip-online-check."  It would be nice if there was also a flag for "--skip-version-check" to stop that from leaking.

all you need is to add the -listen

[etotheipi]

Then start armory with "--skip-online-check."  It would be nice if there was also a flag for "--skip-version-check" to stop that from leaking.

Adding that right now...

[katyhik]

My Armory client doesn't see the coins in my wallet.
I sent the coins to the address on the Armory, Armory showed them on my balance. But after I closed the program (kill process) and opened it, the address is in my wallet, but coins it does not see. All blocks have synchronized. The client has connected to the network. Blockchain confirmed the coins on the adress. I restarted the client a lot of time. But the balance on wallet is zero.

Is Bitcoin-Qt finished synchronizing with the network?  How long has it been since you sent it?  Does blockchain.info show it as having any confirmations (you can right-click on the address in your wallet and click "Show on Blockchain.info")?  

If it has confirmations in Blockchain.info but Armory doesn't show it, then it's likely that for some reason Bitcoin-Qt isn't up to date (still synchronizing?).  The current block (as of this writing) is 215,197.  What does it say in the bottom-right corner of Armory?  If everything is normal, it should say something close, like "Connected (215197 blocks)".  If that doesn't match the latest block on Blockchain.info or blockexplorer, please check Bitcoin-Qt.  In the bottom right you can mouse-over the green checkmark and it should say 215,197.

Yes, Bitcoin-Qt is  finished synchronizing with the network. After the transaction has passed  3 hours. Armory show: Connected (215194) -all blocks synchronized, but the wallet was empty. But now the coins reappear in my wallet. What was the problem before, I don't understand.
Thanks.

[etotheipi]

My Armory client doesn't see the coins in my wallet.
I sent the coins to the address on the Armory, Armory showed them on my balance. But after I closed the program (kill process) and opened it, the address is in my wallet, but coins it does not see. All blocks have synchronized. The client has connected to the network. Blockchain confirmed the coins on the adress. I restarted the client a lot of time. But the balance on wallet is zero.

Is Bitcoin-Qt finished synchronizing with the network?  How long has it been since you sent it?  Does blockchain.info show it as having any confirmations (you can right-click on the address in your wallet and click "Show on Blockchain.info")?  

If it has confirmations in Blockchain.info but Armory doesn't show it, then it's likely that for some reason Bitcoin-Qt isn't up to date (still synchronizing?).  The current block (as of this writing) is 215,197.  What does it say in the bottom-right corner of Armory?  If everything is normal, it should say something close, like "Connected (215197 blocks)".  If that doesn't match the latest block on Blockchain.info or blockexplorer, please check Bitcoin-Qt.  In the bottom right you can mouse-over the green checkmark and it should say 215,197.

Yes, Bitcoin-Qt is  finished synchronizing with the network. After the transaction has passed  3 hours. Armory show: Connected (215194) -all blocks synchronized, but the wallet was empty. But now the coins reappear in my wallet. What was the problem before, I don't understand.
Thanks.

Is it possible that it took 3 hours for the transaction to get 1 confirmation?  When it first appeared, did it have one confirmation?  Or was it already confirmed.  Armory has a problem (Windows only) that it doesn't remember zero-confirmation transactions between loads.  So, if it takes 3 hours to get one confirmation ,and you restart Armory right after you send it, you won't see it for that long.

[etotheipi]

Hi Alan,

Re: having a lite version of Armory.
Have you looked at the Bloom filter work that should be going into bitcoin-QT v0.8 ?

The Bloom filter is set on the server side so you only download the relevant tx.
Makes it O(size of your wallet). Mike Hearn and Matt Corallo have also been adding support into bitcoinj for it.

For mobile apps it should be good as it reduces the (expensive) data they consume. 

Of course there are several ways to do things.

I understand bloom filters, but I haven't understood how they are used in this context.  Is it:  you send a peer your bloom filter (after your addresses have been applied to it), and they filter out all transactions for which none of the recipient addresses match your bloom filter?  You probably get false positives, but dramatically reduced set.

Although, I thought the filters were generally pretty big, so I wasn't clear how easy it was to share them with other peers.  I'm very interested in this idea, nonetheless.  I'm going to go back to my new wallets, and if I see a link pointing me to where I can learn more about them implementing bloom filters in Bitcoin, I'll happily take a break to read it

[jim618]

Hi Alan,

That is basically it as I understand it.

The client creates a Bloom filter for the addresses in its wallet(s) and then sets it on the connection (at the bitcoind end, if you like). The bitcoind then applies the filter to all the traffic before it sends it back.

You can bump up the false positive rate as much as you like (+100%, + 1000%, whatever) to trade off privacy at the cost of more bandwidth.

I think from the wiki on it you need about 10 bits per 'unique thing you want to distinguish' so I expect they would have to be kilobit size to be useful.   I'm not sure where the branch is with the bloom filter dev work in to be honest - hopefully someone will chip in!

[etotheipi]

Check out the new QR stuff in the testing branch!

If you like it enough and use smartphones a lot, you can donate here:

[etotheipi]

Reposted from the BOUNTIES thread:



Okay!  Since I'm hoping to make this an official release, I've upped the bounties to 0.2 BTC.  Yes, that's almost $3 per bug!  

However for this round, smaller bugs like most of what subSTRATA was posting will not be considered for the 0.2 BTC.  I already fixed 21 bugs/suboptimal features based on subSTRATA's diligent testing, but for this release I'm really looking for the big things that actually prevent users from using the features of the software.  Usually this is stuff like transactions not sending because I broke some networking code, or dialogs that are don't show up, or display garbage.  And of course, crashing.   The minor bugs and polishing will still be rewarded, but only 0.05 BTC.

This version has full QR-code integration and copying payment request links in Windows finally seems to work.  I have also uploaded the new releases to code.google.com because it has all the features I need in a project-hosting site:  scriptable uploads, download counting, folders, etc.

http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_win64.msi
http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_windows_all.msi

And since this is a new download location, I have signed the SHA1 hashes using the offline signing key, in case anyone wants to verify them.  The nice thing is that google-code shows you the hash there (though it's still preferred you hash the downloaded file, to be sure).  

http://bitcoinarmory.googlecode.com/files/armory_0.86.7-testing_sha1.txt.asc

And just in case you find GPG/PGP annoying, here's a signed message, ironically using Armory's message-signing interface that I said was offlimits for bug reports (it works, but it's messy and hasn't been maintained for a while.  Simply go to "Tools-->Message Signing" and then click on "Import Signature Block" and copy the following text into it:

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:    "2013-Jan-06 02:51pm -- Downloadable Armory insta"
            "llers will now be hosted at http://bitcoinarmory"
            ".googlecode.com.  The first release at this new "
            "location is version 0.86.7-testing, and has the "
            "following SHA1 hashes --  64-bit version: 3f6a4a"
            "c9cdb98c421c883e15cf0acd52b7c25d31 and 32-bit ve"
            "rsion:  f3f3ee3de0d0434f1fd41664f456e755efaed1e2"
PublicKey:  0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
            b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
            7571cbe492a7222442b75df75b9a84
Signature:  77a6f9a9e28b92b730216c5c6e62b89f6336d36e4bb1a0cbc3
            42d5f3a6d5d9ea4032cafe8b3d7e9be249aac4b79bf663f96f
            5ac4662d4f18ee4e76514ce8087c
-----END-SIGNATURE-BLOCK---------------------------------------

[HostFat]

I have a feature request
- Wherever is shown a QR-code, if the user double-click on it then it will enlarge to take all the screen (mainly).
Double click again and it will back small.

[etotheipi]

I have a feature request
- Wherever is shown a QR-code, if the user double-click on it then it will enlarge to take all the screen (mainly).
Double click again and it will back small.

I suppose that wouldn't be too hard to do.  But what is the application?  So that you can show someone a QR code from the other end of the airport terminal?

[HostFat]

I suppose that wouldn't be too hard to do.  But what is the application?  So that you can show someone a QR code from the other end of the airport terminal?

It's useful if you are behind a desk in a shop, and you need to show the QR-code and only it to the customer.
Multibit has the same feature.

[casascius]

I suppose that wouldn't be too hard to do.  But what is the application?  So that you can show someone a QR code from the other end of the airport terminal?

It's useful if you are behind a desk in a shop, and you need to show the QR-code and only it to the customer.
Multibit has the same feature.

I can see the value as well: some phones do a piss-poor job of focusing up close.  By allowing it to focus on a full screen several feet away, that problem is solved.

[etotheipi]

I suppose that wouldn't be too hard to do.  But what is the application?  So that you can show someone a QR code from the other end of the airport terminal?

It's useful if you are behind a desk in a shop, and you need to show the QR-code and only it to the customer.
Multibit has the same feature.

I can see the value as well: some phones do a piss-poor job of focusing up close.  By allowing it to focus on a full screen several feet away, that problem is solved.

Agreed.  I just wanted to understand the application to make sure the feature makes sense, and maybe I can add something other twists that would further improve it.

In this case, I'm not sure I can improve it further.  Sounds like "make-it-BIG" is precisely what's needed.  It should be pretty easy to implement, so I should be able to get it into the next release (which will hopefully be soon!).

On that note, please help test and find bugs!  kthxbye

[xxjs]

Feature request: In addition to the existing passwords for the wallets, which are really passwords covering the secret keys of the wallets, it would be nice to have a password for viewing. Now, starting Armory, all the balances and addresses are shown directly.

[etotheipi]

Feature request: In addition to the existing passwords for the wallets, which are really passwords covering the secret keys of the wallets, it would be nice to have a password for viewing. Now, starting Armory, all the balances and addresses are shown directly.

Ah hah!  It's funny you bring that up, because I was just in the process of designing my new wallets in such a way this would be possible.  It probably won't be enabled on the first release, but I'm putting "EncryptionObject" entries next to each wallet entry which could be used to implement exactly what you just requested. 

It's becoming quite a massive undertaking, as I've ended up basically rewriting the wallets from scratch.  But it's being rewritten in order to give it the flexibility to things like this without redesigning it again. 

The only problem is that this passphrase will be typed all the time, and the encryption key will have to sit in memory the whole time Armory is open.  There's no way users will pick a different passphrase for their private keys and their public keys, and that makes this a pretty significant risk...  I might only offer the feature on offline/watching-only wallets and plaster warnings everywhere (not that it necessarily helps, but users should be aware of the risks they take by using passwords that protect important things, on things that aren't that important).

But I totally appreciate the desire to not have someone steal your laptop and learn (1) that you have $100k BTC probably at your house on an offline computer and (2) the address to your house.

[K1773R]

What about keyfiles?

[picobit]

  There's no way users will pick a different passphrase for their private keys and their public keys, and that makes this a pretty significant risk... 

Actually, blockchain.info essentially does this, and I did not even consider making the two passwords the same.  Anyway, it should be easy to disallow that the two are identical.

[Carlton Banks]

Feature request: In addition to the existing passwords for the wallets, which are really passwords covering the secret keys of the wallets, it would be nice to have a password for viewing. Now, starting Armory, all the balances and addresses are shown directly.

Ah hah!  It's funny you bring that up, because I was just in the process of designing my new wallets in such a way this would be possible.  It probably won't be enabled on the first release, but I'm putting "EncryptionObject" entries next to each wallet entry which could be used to implement exactly what you just requested. 

That'd be amazing if you could get this dealt with too: I have a tendency to use long passwords to encrypt wallets, and some passwords tend to get forgotten, so I end up restoring from paper backup and choosing a new phrase (never, ever write them down). Giving users the option to force them into unlocking the public keys on block loading completion would help overcome this through the repetition, and the fact it'd also be a useful security feature in it's own right is more than a bonus. I may be able to get Armory directly onto my desktop too, as I'm currently using an encrypted VM to provide the same function (just wouldn't currently dare to use the wallet phase to encrypt the VM, you'd be saving me a whole load of RAM overhead and put off me whining about the RAM heavy thing too!)

[HostFat]

More about the make-it-BIG qr-code feature request.
Sometimes it's also needed that it's big as the fullscreen, because I "want" to hide everything else.
I don't want that the customer is able to see something else running on the computer while is taking the qr-code.

[xxjs]

Feature request: In addition to the existing passwords for the wallets, which are really passwords covering the secret keys of the wallets, it would be nice to have a password for viewing. Now, starting Armory, all the balances and addresses are shown directly.

The only problem is that this passphrase will be typed all the time, and the encryption key will have to sit in memory the whole time Armory is open.  There's no way users will pick a different passphrase for their private keys and their public keys, and that makes this a pretty significant risk...  I might only offer the feature on offline/watching-only wallets and plaster warnings everywhere (not that it necessarily helps, but users should be aware of the risks they take by using passwords that protect important things, on things that aren't that important).

But I totally appreciate the desire to not have someone steal your laptop and learn (1) that you have $100k BTC probably at your house on an offline computer and (2) the address to your house.

I would not have a problem with dealing with a separate password for this.