Armory - Discussion Thread

[goatpig]

1) Copy and paste your bitcoin.conf content in here

2) Armory needs 2 things: To find a running instance of Bitcoin locally (on 127.0.0.1:8333) that it can connect to) and to be pointed at the folder where the blockchain is saved. Now I need a logfile to assert that. Make a ticket, attach the log and point at your post.

3) If you dont know it means you didnt mess with it.

4&6) Armory connects to Bitcoin locally and to our own servers for updates and announcements. This has been the case since... hell I dont remember but its been there alright. Look at your log file and watch all those connections to google.com and our s3 server. At this rate it would be simpler to install Whonix than go through all this pain. If you dont have any coding experience you're gonna have a hard time turning off all side channel in the from source. This isnt related to your issue btw, just assuming you want all that side channel stuff off or going through Tor.

5) Same as 1)

Also, you should be able to put all your settings in the bitcoin.conf file and let Armory auto manage it, but that's besides the point. Using 64 vs 32bit BitcoinQt has nothing to do with this, this is simply a setting issue. Give me the information I need and I'll sort it out.

Again consider using Whonix or that Tails + Armory attempt found somewhere on this sub section.

Something I forgot to answer: We dont put out a 64bit Windows version anymore because we dont need to. When Armory needed tons of RAM it had to be 64 bit. Now it doesn't anymore so we don't bother in a sense. The 32 bit version runs on every supported Windows, make our life easier.

[Rampion]

The only way to have Armory working with Tor is to have listen=1 on bitcoin.conf, or to start bitcoin with the -listen=1 argument, right?

[goatpig]

The only way to have Armory working with Tor is to have listen=1 on bitcoin.conf, or to start bitcoin with the -listen=1 argument, right?

addnode=127.0.0.1 will make bitcoind try to connect to Armory, which is what you want, and not more. listen=1 is more aggressive than necessary.

[Rampion]

The only way to have Armory working with Tor is to have listen=1 on bitcoin.conf, or to start bitcoin with the -listen=1 argument, right?

addnode=127.0.0.1 will make bitcoind try to connect to Armory, which is what you want, and not more. listen=1 is more aggressive than necessary.

Tried to start Bitcoin-QT (I'm using OSX and thus no bitcoind self management) with the following arguments, to no avail:

Code:

-addnode=127.0.0.1
-addnode=127.0.0.1:9150
-addnode=localhost
-addnode=localhost:9150

Armory says it is offline.

Didn't try to add that to bitcoin.conf, but I guess that the result should be the same as if I start the client from the commad line with the aforementioned arguments?

The only way I got armory to work with tor is with -listen=1, which I do not like too much as I worry I'm exposing my Bitcoin client to the world.

[goatpig]

I thought OSX has issues with command line arguments. Add it to the .conf and get back to me.

Also, why :9150? Is this your personal setting? If so you have to set Armory to use that port too.

[doug_armory]

I thought OSX has issues with command line arguments.

CL args are okay as of 0.91.

[redphlegm]

First of all, my apologies if I'm going the wrong route for this type of question. I realize the development team has a very full plate with development and responding to threads such as this. If proper protocol is to plug this into an issue / suggesting tracking system, I would be happy to do so - I just didn't see one in my looking around.

I also didn't see the answer to this question anywhere else. I saw some mention of it from a year ago where it was a single line change in the python code but this question reaches beyond that, I think. Let me describe my scenario:

Let's say I am dealing with many machines (for the sake of conversation, let's say 2 desktops, 2 laptops, and an offline machine I use for Armory cold storage - all with various OS's). I would like to be able to have a master machine that is responsible for downloading the blockchain and maintaining it for the rest of the machines (especially the laptops since they have limited storage on SSDs). Is there a way to accomplish this? Ideally I would set up Desktop A as the main client that is on all the time and downloads the blockchain. The rest of the machines would use that copy of the blockchain, ideally. I don't necessarily care if the Armory DB is locally stored (for instance having it on a NAS or something on the same network). It would still be a lot less storage overhead than I'm currently dealing with.

Thanks in advance.

[Carlton Banks]

First of all, my apologies if I'm going the wrong route for this type of question. I realize the development team has a very full plate with development and responding to threads such as this. If proper protocol is to plug this into an issue / suggesting tracking system, I would be happy to do so - I just didn't see one in my looking around.

I also didn't see the answer to this question anywhere else. I saw some mention of it from a year ago where it was a single line change in the python code but this question reaches beyond that, I think. Let me describe my scenario:

Let's say I am dealing with many machines (for the sake of conversation, let's say 2 desktops, 2 laptops, and an offline machine I use for Armory cold storage - all with various OS's). I would like to be able to have a master machine that is responsible for downloading the blockchain and maintaining it for the rest of the machines (especially the laptops since they have limited storage on SSDs). Is there a way to accomplish this? Ideally I would set up Desktop A as the main client that is on all the time and downloads the blockchain. The rest of the machines would use that copy of the blockchain, ideally. I don't necessarily care if the Armory DB is locally stored (for instance having it on a NAS or something on the same network). It would still be a lot less storage overhead than I'm currently dealing with.

Thanks in advance.

You're not the first to ask this question, and I believe the answer is still "not yet". It's possible that it's been implemented in 0.9x and I didn't notice it, but I don't think that's the case. The developers are aware of requests for this type of thing though, and have stated a commitment to providing the feature in the past.

[Ente]

First of all, my apologies if I'm going the wrong route for this type of question. I realize the development team has a very full plate with development and responding to threads such as this. If proper protocol is to plug this into an issue / suggesting tracking system, I would be happy to do so - I just didn't see one in my looking around.

I also didn't see the answer to this question anywhere else. I saw some mention of it from a year ago where it was a single line change in the python code but this question reaches beyond that, I think. Let me describe my scenario:

Let's say I am dealing with many machines (for the sake of conversation, let's say 2 desktops, 2 laptops, and an offline machine I use for Armory cold storage - all with various OS's). I would like to be able to have a master machine that is responsible for downloading the blockchain and maintaining it for the rest of the machines (especially the laptops since they have limited storage on SSDs). Is there a way to accomplish this? Ideally I would set up Desktop A as the main client that is on all the time and downloads the blockchain. The rest of the machines would use that copy of the blockchain, ideally. I don't necessarily care if the Armory DB is locally stored (for instance having it on a NAS or something on the same network). It would still be a lot less storage overhead than I'm currently dealing with.

Thanks in advance.

Yes, it's been asked before, but it's not implemented yet.

The closest you can get to that is to either

- have one machine with a regular "online" Bitcoin node, connected to the internet
- have all other local clients connect to that "online" node only, with two full blockchains on every node still

- use a different, light client, like electrum for example. You could even set up your own electrum server on one computer, as I understand it

The general problem, I believe, is that several computers accessing and writing to the same (blockchain-)database will immediately corrupt it, if no precautions are made. So this feature would need a lot of changes under the hood. And probably has a somewhat low demand, for that much effort, compared to other features..

I'm in your boat here. And I run a local "always on" node, where all other nodes connect to when they run, from time to time.

Ente

[Rampion]

I thought OSX has issues with command line arguments. Add it to the .conf and get back to me.

Also, why :9150? Is this your personal setting? If so you have to set Armory to use that port too.

Still not working. I tried with port 9150 too because that's the port Tor uses. Any idea on how to fix this?

EDIT: just made it work. I had to start Armory with the following argument: --satoshi-port=9150

[Rampion]

An update on my work in progress to get Armory to work with Tor on OSX 10.9.2 and Bitcoin Core 0.9.1

There are only two ways in which I succeed:

a) I start Bitcoin Core with the -listen=1 argument. I'm a bit fearful of this solution because while I understand what "listening to incoming connections" means, I'm not sure what are the risks involved - I'm behind a NAT router and I should probably be OK, but I'm not confident because I don't understand what kind of attack I might suffer with this config. Using -listen=1 with Bitcoin Core I just start Armory normally and it works perfectly.

b) I start Armory with the --satoshi-port=9150 argument (note: 9150 is the port Tor uses, and through which my Bitcoin Core connects). With this solution I don't need any argument on Bitcoin Core (obviously not "listen=1", but neither "addnode=127.0.0.1"), it just works... But there is a tradeoff. Armory is less stable and while it synchs OK, scans transactions correctly, and displays the right balance, the connected/disconnected word in the right bottom corner blinks non stop, switching from "discconected" to "connected" like crazy - same thing happens with the Offline/Online word on the main screen.

Just to be clear, I have this issues only because I'm using Tor, if I remove the proxy settings from Bitcoin Core thus not routing it through Tor Armory just works great without any additional arguments on Bitcoin Core or Armory.

[cypherdoc]

so i just upgraded to satoshi 0.9.1.   i failed to delete 0.9.0 so how do i tell which version Armory is running off of?

[goatpig]

An update on my work in progress to get Armory to work with Tor on OSX 10.9.2 and Bitcoin Core 0.9.1

There are only two ways in which I succeed:

a) I start Bitcoin Core with the -listen=1 argument. I'm a bit fearful of this solution because while I understand what "listening to incoming connections" means, I'm not sure what are the risks involved - I'm behind a NAT router and I should probably be OK, but I'm not confident because I don't understand what kind of attack I might suffer with this config. Using -listen=1 with Bitcoin Core I just start Armory normally and it works perfectly.

b) I start Armory with the --satoshi-port=9150 argument (note: 9150 is the port Tor uses, and through which my Bitcoin Core connects). With this solution I don't need any argument on Bitcoin Core (obviously not "listen=1", but neither "addnode=127.0.0.1"), it just works... But there is a tradeoff. Armory is less stable and while it synchs OK, scans transactions correctly, and displays the right balance, the connected/disconnected word in the right bottom corner blinks non stop, switching from "discconected" to "connected" like crazy - same thing happens with the Offline/Online word on the main screen.

Just to be clear, I have this issues only because I'm using Tor, if I remove the proxy settings from Bitcoin Core thus not routing it through Tor Armory just works great without any additional arguments on Bitcoin Core or Armory.

Do not use this port. You are letting Armory connect through the Tor proxy. That's bad, Armory could possibly connect to an outside node this way, and this is what I think you are seeing with the massive disconnect.

I'm busy right now but I'll setup the Tor proxy later tonight and figure out a proper setting.

[Rampion]

An update on my work in progress to get Armory to work with Tor on OSX 10.9.2 and Bitcoin Core 0.9.1

There are only two ways in which I succeed:

a) I start Bitcoin Core with the -listen=1 argument. I'm a bit fearful of this solution because while I understand what "listening to incoming connections" means, I'm not sure what are the risks involved - I'm behind a NAT router and I should probably be OK, but I'm not confident because I don't understand what kind of attack I might suffer with this config. Using -listen=1 with Bitcoin Core I just start Armory normally and it works perfectly.

b) I start Armory with the --satoshi-port=9150 argument (note: 9150 is the port Tor uses, and through which my Bitcoin Core connects). With this solution I don't need any argument on Bitcoin Core (obviously not "listen=1", but neither "addnode=127.0.0.1"), it just works... But there is a tradeoff. Armory is less stable and while it synchs OK, scans transactions correctly, and displays the right balance, the connected/disconnected word in the right bottom corner blinks non stop, switching from "discconected" to "connected" like crazy - same thing happens with the Offline/Online word on the main screen.

Just to be clear, I have this issues only because I'm using Tor, if I remove the proxy settings from Bitcoin Core thus not routing it through Tor Armory just works great without any additional arguments on Bitcoin Core or Armory.

Do not use this port. You are letting Armory connect through the Tor proxy. That's bad, Armory could possibly connect to an outside node this way, and this is what I think you are seeing with the massive disconnect.

I'm busy right now but I'll setup the Tor proxy later tonight and figure out a proper setting.

Ok, I just crapped my pants - I won't be using --satoshi-port=9150 anymore, I think you are right and I was connecting to an outside node (while I had massive disconnections, synch and balances were OK all the time, so Armory wasn't in "offline" mode but connected to a node).

[Ente]

Ok, I just crapped my pants - I won't be using --satoshi-port=9150 anymore, I think you are right and I was connecting to an outside node (while I had massive disconnections, synch and balances were OK all the time, so Armory wasn't in "offline" mode but connected to a node).

..good thing all blocks are cryptographically signed and will be verified locally, right? :-)

Ente

[goatpig]

Ok, I just crapped my pants - I won't be using --satoshi-port=9150 anymore, I think you are right and I was connecting to an outside node (while I had massive disconnections, synch and balances were OK all the time, so Armory wasn't in "offline" mode but connected to a node).

..good thing all blocks are cryptographically signed and will be verified locally, right? :-)

Ente

Armory doesnt verify the blocks it reads, it trusts Bitcoin Core to do that. Ill let you imagine how nasty that can get when an attacker gets to connect to your instance of Armory as its "good" node.

Got it work in a somewhat acceptable setting.

This is my bitcoin.conf:

proxy=127.0.0.1:9050
listen=1
port=8331

My Tor is set to run its proxy on 9050 by default.
8331 is a port I chose for Armory to connect to. Armory has to run with the --satoshi-port=8331 switch.

In my firewall, I added a rule to block all network traffic to port 8331. This way only localhost can connect to a socket listening on that port. This seems to work fine. Observing bitcoin, it only connects to nodes through the Tor proxy besides Armory, locally.

[Ente]

Ok, I just crapped my pants - I won't be using --satoshi-port=9150 anymore, I think you are right and I was connecting to an outside node (while I had massive disconnections, synch and balances were OK all the time, so Armory wasn't in "offline" mode but connected to a node).

..good thing all blocks are cryptographically signed and will be verified locally, right? :-)

Ente

Armory doesnt verify the blocks it reads, it trusts Bitcoin Core to do that. Ill let you imagine how nasty that can get when an attacker gets to connect to your instance of Armory as its "good" node.

Oopsie.. 

Got it work in a somewhat acceptable setting.

This is my bitcoin.conf:

proxy=127.0.0.1:9050
listen=1
port=8331

My Tor is set to run its proxy on 9050 by default.
8331 is a port I chose for Armory to connect to. Armory has to run with the --satoshi-port=8331 switch.

In my firewall, I added a rule to block all network traffic to port 8331. This way only localhost can connect to a socket listening on that port. This seems to work fine. Observing bitcoin, it only connects to nodes through the Tor proxy besides Armory, locally.

Thank you! I too will eventually play with bitcoin, Armory and TOR.

Since we are at it already: It shouldn't make any problems to have one bitcoin-core listen/connect to both TOR and clearnet, through two ports,  at the same time? It would be some kind of bitcoin clearnet-TOR gateway that way I imagine..

Ente

[goatpig]

Testing that now actually.

[Rampion]

Ok, I just crapped my pants - I won't be using --satoshi-port=9150 anymore, I think you are right and I was connecting to an outside node (while I had massive disconnections, synch and balances were OK all the time, so Armory wasn't in "offline" mode but connected to a node).

..good thing all blocks are cryptographically signed and will be verified locally, right? :-)

Ente

Armory doesnt verify the blocks it reads, it trusts Bitcoin Core to do that. Ill let you imagine how nasty that can get when an attacker gets to connect to your instance of Armory as its "good" node.

Got it work in a somewhat acceptable setting.

This is my bitcoin.conf:

proxy=127.0.0.1:9050
listen=1
port=8331

My Tor is set to run its proxy on 9050 by default.
8331 is a port I chose for Armory to connect to. Armory has to run with the --satoshi-port=8331 switch.

In my firewall, I added a rule to block all network traffic to port 8331. This way only localhost can connect to a socket listening on that port. This seems to work fine. Observing bitcoin, it only connects to nodes through the Tor proxy besides Armory, locally.

If I add only "listen=1" to bitcoin.conf and I run Armory with no arguments whatsoever it works fine, how is that more insecure/worst than the set up you suggest? I don't seem to need "port=8331" in bitcoin.conf nor the "--satoshi-port=8331" argument for Armory, all the additional steps you mention seem to complicate the process unnecesarily.

[goatpig]

I dont know the range of connections listen=1 allows. Changing the default port and blocking all external traffic to it takes care of potential surprises.