Topic: Bitcoin-QT/bitcoind on a different machine? (Read 3514 times)

There shouldn't be a dot

I've set up a node on my network that talks to the internet and runs 24/7.
If I need armory on a second pc on my network I setup bitcoin cleint on the second pc to -connect=192.168.x.x in the bitcoin.conf.  This means the additional node only talks to my existing node and no other nodes.  So it only uses internal bandwidth to sync up. 
The diskspace is still wasted but at least I could move the additional node to online quite easily if I wanted to.

I wouldn't do this on a laptop though as the 192.168.x.x could point to any pc if you connect on another (untrusted) network.

I'm hoping to setup the same type of thing. Here's my situation:

* Linux machine with full node & P2pool (miners pointing here...) (port 8333 forwarded)
* Mac with Armory, Bitcoin-qt & potentially Ubuntu VM
* A couple other client computers (potentially)
* Synology NAS

Since I'm running that full node, I'd like to use it's blockchain throughout my LAN where I may need it. I tried setting the RPC connect value:

rpcconnect=10.0.1.XXX

But it doesn't seem to pick it up. I did that in /Library/Application Support/Bitcoin/.bitcoin.conf and restarted Bitcoin-qt, but it goes back to trying to sync, slowly as usual. Would it help if I used a connect setting to hit my local node?

connect=10.0.1.XXX:8333

I'm wondering if it would make more sense to try to involve the NAS? Like to (and I haven't done this with Linux yet) create a share and use it for my blockchain on the full node, and then on the other clients? I have a gigabit, wired network with the NAS and full node machine adjacent, so imagine it would be quick enough. Then I could potentially mount that share to any client that wanted it... would this work? Or would the various clients wind up foobarring the blockchain?

Seems like there should be an easy way to share a networked bitcoind on a trusted LAN, but it seems to be eluding me. Or is the db just designed to be single-user and this is asking for trouble?

I think bitcoind doesn't blacklist localhost though.

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L4004

This is where is does the local check

https://github.com/bitcoin/bitcoin/blob/master/src/netbase.cpp#L682

It checks for the IP6 loopback (all zeros and then a one) and the IP4 loopback (addr[3] == 127 or 0)

So if using maxconnections what can I do to reserve a connection for armory?

Try running bitcoind or bitcoin-qt in the guest as well.  Just be absolutely sure not to run it simultaneously on the host and guest if you share the directory!

Related question: I am wondering if it would be possible to run it on a VM on a machine where Bitcoin-qt is running. Armory runs very poorly on my desktop (OS-X) and frequently crashes after taking all day to read in the blockchains so I would like to run it in a linux VM. I have Armory running in a linux VM with a much smaller footprint (OS included) than it was using on the host machine. Armory runs very smoothly in the guest OS. I have set up shared folders to mount ~/Library/Application Support/Bitcoin to ~/.bitcoin and I have copied my Armory wallets into the new OS. I have used bridged mode for the network interface on the guest. However, when I start up Armory, it reports that it is in offline mode. What can I do about this?

Close!  Armory actually doesn't use the RPC connection, it connects as a regular peer through localhost.  Some people have problems with this because they assume it's RPC, and setup their bitcoin.conf to only accept connections from certain IPs, thinking that Armory will sidestep it through RPC. 

However, it only uses that connection for new blocks and transactions.  It still relies on the BTC_HOME_DIR/blocks/blk*.dat files to read the past blockchain history.  Now that Armory is maintaining its own database, I can transition off of using the blk*.dat files and only use the peer connection.  But there may be some hurdles there:

(1) Bitcoin-Qt/bitcoind cutting me off because I'm demanding too many resources and it blacklists me
(2) Please dear god do not connect Armory to an untrusted node!.  You will die a fiery death.  Armory does absolutely no blockchain validation: it is designed to use that connection as its secure gateway.   

I want to eventually allow remote connections, but then also make it painfully obvious that there is a serious risk involved.  You might even want to use some kind of SSL to make sure you remote connection is not intercepted.  None of this matters though when it's forced to use localhost...

Communication with Qt is done through the RPC server, however (don't quote me on this) I think it is hardcoded to localhost. Assuming you get accross this hurdle (or that I'm wrong), you still need to give Armory the raw block chain files path. Through a network share, I assume.

I was wondering if it is possible to run Bitcoin-QT/bitcoind on a computer on my local LAN and then have Armory access/communicate with that computer in lieu of running Bitcoin-QT on the same machine that has Armory installed? The idea is to have Bitcoin-QT run continuously on the one computer and then have Armory communicate with it as needed.