Topic: Connect to non-local bitcoind? (Read 4321 times)
Bump
New armory also doubles storage
But I don't mind.
I'm just having problems using maxconnections and reserving a connection for armory
But I don't mind.
I'm just having problems using maxconnections and reserving a connection for armory
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 to -connect=192.168.x.x in the bitcoin.conf. This means the additional node only talks to my 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.
If I need armory on a second pc on my network I setup bitcoin cleint to -connect=192.168.x.x in the bitcoin.conf. This means the additional node only talks to my 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.
That's a good way, yes.
I did that in my android bitcoin wallet (Schildbach), setting the trusted IP to the node in my LAN. Saves bandwith and sync time. It's just a static additional IP though, so my wallet connects just fine too when I'm on mobile.
Ente
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 to -connect=192.168.x.x in the bitcoin.conf. This means the additional node only talks to my 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.
If I need armory on a second pc on my network I setup bitcoin cleint to -connect=192.168.x.x in the bitcoin.conf. This means the additional node only talks to my 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.
It's ridiculous to have 3 sets of the same 7Gb data connected to other peers through a single IP address... my home ADSL line.
It is not ridiculous for me to have another full copy at work, that being on an entirely different IP.
Electrum isn't quite what I'm looking for either, as that connects to public servers. I do want to run 'A' Full node. A cursory look doesn't show me how to create my own private electrum server, though I'm sure it's possible.
Maybe when Armory handles the full node itself, it could also act as a server to other Armory clients.
It is not ridiculous for me to have another full copy at work, that being on an entirely different IP.
Electrum isn't quite what I'm looking for either, as that connects to public servers. I do want to run 'A' Full node. A cursory look doesn't show me how to create my own private electrum server, though I'm sure it's possible.
Maybe when Armory handles the full node itself, it could also act as a server to other Armory clients.
..as we are all happily necro'ing anyway:
The solution might be to setup your own Electrum server. Then connect all local Electrum clients to that one.
For everyone not liking the dublicate data: every single additional (full) node helps the network. That's how I see it, and leave my bitcoind running all the time.
Ente
It's probably also worth pointing out that localhost being trustworthy is an assumption also.
Eagerly looking forward to the day in which I can run btcd and Armory together and not need the Satoshi client at all.
+1 FWIW. My use case would probably be running both bitcoind and Armory on the same machine, but under different user accounts. And I don't want to mess with symlinks and file permissions. Just keep stuff isolated.
I think you should make the option to connect to a non-local bitcoind a little easier and have a big warning not to use servers which you don't have control over. If the user still needs to manually set up network shares, and map drives etc. to allow access to the data files, then you won't be able to 'accidentally' connect to a non-trusted server... you'll REALLY have to put effort in to it. As with anything in the bitcoin world, let people do whatever they want and caveat emptor.
Zombie thread.
+1 on this here. I have a bitcoin-qt client, looking to do the armory thing. See no reason I should have to download the blockchain all over again. I may not even have space, I'm trying it out on a VM Ubuntu box.
I think you should make the option to connect to a non-local bitcoind a little easier and have a big warning not to use servers which you don't have control over. If the user still needs to manually set up network shares, and map drives etc. to allow access to the data files, then you won't be able to 'accidentally' connect to a non-trusted server... you'll REALLY have to put effort in to it. As with anything in the bitcoin world, let people do whatever they want and caveat emptor.
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for.
I think the default configuration for most users is that they operate on a trusted network, whether that is a home LAN, or a business network. If I operate both machines, then neither one is an untrusted peer to the other.Perhaps you can loosen the rules a bit to allow Armory to consider any host on the same non-public address block (ipv4) or on a link-local address (ipv6) to be considered a trusted peer, and not just 127.0.0.1 without compromising security appreciably.
Technically, it's not restricted right now. I've had a couple users tell me they setup their --satoshi-datadir on the an nfs or sshfs directory, and pointed Armory to the remote host. There's no command line option for it, but most of these people are running Linux, and it's a one-line change in the python code. I *could* add a command line option, but I will wait until I have the semi-independent blockchain management. If I added the option right now, it would be worthless to most users...
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for.
I think the default configuration for most users is that they operate on a trusted network, whether that is a home LAN, or a business network. If I operate both machines, then neither one is an untrusted peer to the other.Perhaps you can loosen the rules a bit to allow Armory to consider any host on the same non-public address block (ipv4) or on a link-local address (ipv6) to be considered a trusted peer, and not just 127.0.0.1 without compromising security appreciably.
The problem here is this:
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for. Right now, there's no choice: Armory relies on localhost Bitcoin-Qt/bitcoind, which if that is compromised, Armory is hosed anyway. The first time it is allowed to connect to non-localhost (after it gets its own blockchain mgmt), I know people will start connecting it to untrusted nodes, not realizing that it's really bad news. Armory has what it has because hiding behind a trusted bitcoind gives it all the security properties of bitcoind, without spending any time developing it (and probably doing a terrible job and forking the blockchain). Instead, I've been able to focus on features, instead of re-doing what the core devs do.
However, at some point, I will be splitting Armory into both directions: lite-node and super-node. The Armory super-node would be like the Electrum servers, allowing arbitrary address lookup. It would be hiding behind a single bitcoind instance, and all the lite-nodes can connect directly to it. I'm sure people will run malicious Armory super-nodes, but at least in this case, Armory lite-node is depending a lot less on that connection: it basically turns their computer into an offline signing system (even though it's technically online) -- the super-node accumulated all the transaction data, and then gives it to the lite-node to sign. Then the lite node can broadcast. I've actually made sure that that process is secure, even if the online computer (or supernode) is malicious.
There's quite a bit of work to do on that front, though...
Armory users will die a fiery death if they connect to an untrusted peer. The reason is that it has no protections whatsoever, from network or protocol shenanigans. This is what bitcoind is for. Right now, there's no choice: Armory relies on localhost Bitcoin-Qt/bitcoind, which if that is compromised, Armory is hosed anyway. The first time it is allowed to connect to non-localhost (after it gets its own blockchain mgmt), I know people will start connecting it to untrusted nodes, not realizing that it's really bad news. Armory has what it has because hiding behind a trusted bitcoind gives it all the security properties of bitcoind, without spending any time developing it (and probably doing a terrible job and forking the blockchain). Instead, I've been able to focus on features, instead of re-doing what the core devs do.
However, at some point, I will be splitting Armory into both directions: lite-node and super-node. The Armory super-node would be like the Electrum servers, allowing arbitrary address lookup. It would be hiding behind a single bitcoind instance, and all the lite-nodes can connect directly to it. I'm sure people will run malicious Armory super-nodes, but at least in this case, Armory lite-node is depending a lot less on that connection: it basically turns their computer into an offline signing system (even though it's technically online) -- the super-node accumulated all the transaction data, and then gives it to the lite-node to sign. Then the lite node can broadcast. I've actually made sure that that process is secure, even if the online computer (or supernode) is malicious.
There's quite a bit of work to do on that front, though...
I wish some the design patterns that emerged in the 90s would just die already.
The case of a single user on a single computer should be treated as a rare exception, not the default use case.
Unix-like operating systems had solved this problem by assuming that all computers were part of a LAN and were used by more than one person. Windows destroyed this paradigm and the industry has never recovered.
The case of a single user on a single computer should be treated as a rare exception, not the default use case.
Unix-like operating systems had solved this problem by assuming that all computers were part of a LAN and were used by more than one person. Windows destroyed this paradigm and the industry has never recovered.
Right.
It's ridiculous to have 3 sets of the same 7Gb data connected to other peers through a single IP address... my home ADSL line.
It is not ridiculous for me to have another full copy at work, that being on an entirely different IP.
Electrum isn't quite what I'm looking for either, as that connects to public servers. I do want to run 'A' Full node. A cursory look doesn't show me how to create my own private electrum server, though I'm sure it's possible.
Maybe when Armory handles the full node itself, it could also act as a server to other Armory clients.
It is not ridiculous for me to have another full copy at work, that being on an entirely different IP.
Electrum isn't quite what I'm looking for either, as that connects to public servers. I do want to run 'A' Full node. A cursory look doesn't show me how to create my own private electrum server, though I'm sure it's possible.
Maybe when Armory handles the full node itself, it could also act as a server to other Armory clients.
Bitcoin wasn't designed with a client-server model in mind and it's causing problems. A single home or business network shouldn't need to store N*M copies of the blockchain and require N*M external connections to the P2P network where N is the number of users and M is the number of devices each user owns.
Yeah, that seriously needs looking at.
At 7GB (or so) sitting on my machine, it's pretty ridiculous to have to repeat the exact same open-for-everyone-to-see information for each user.
Research P2P architecture, so while you think it is ridiculous it is the proper way.
I wish some the design patterns that emerged in the 90s would just die already.
The case of a single user on a single computer should be treated as a rare exception, not the default use case.
Unix-like operating systems had solved this problem by assuming that all computers were part of a LAN and were used by more than one person. Windows destroyed this paradigm and the industry has never recovered.
The case of a single user on a single computer should be treated as a rare exception, not the default use case.
Unix-like operating systems had solved this problem by assuming that all computers were part of a LAN and were used by more than one person. Windows destroyed this paradigm and the industry has never recovered.
I don't REALLY need it... but what if I want a copy on my machine, girlfriends machine, kitchen machine, someone else's machine etc.?
Have to install a full client on each? That's a whole lot of redundant data!
Sharing the data directory is entirely possible, but then where do I specify where Armory should look for these?
Running armory on a ton of systems does have lots of duplicate data. Maintaining a full node on all your systems always will. Have to install a full client on each? That's a whole lot of redundant data!
Sharing the data directory is entirely possible, but then where do I specify where Armory should look for these?
Eventually armory will handle all of the blockchain data itself, but that won't solve your issue with duplicate data.
If you want a client that doesn't need a ton of local data, you want a lite client like electrum.
Bitcoin wasn't designed with a client-server model in mind and it's causing problems. A single home or business network shouldn't need to store N*M copies of the blockchain and require N*M external connections to the P2P network where N is the number of users and M is the number of devices each user owns.
Yeah, that seriously needs looking at.
At 7GB (or so) sitting on my machine, it's pretty ridiculous to have to repeat the exact same open-for-everyone-to-see information for each user.
Bitcoin wasn't designed with a client-server model in mind and it's causing problems. A single home or business network shouldn't need to store N*M copies of the blockchain and require N*M external connections to the P2P network where N is the number of users and M is the number of devices each user owns.
I don't REALLY need it... but what if I want a copy on my machine, girlfriends machine, kitchen machine, someone else's machine etc.?
Have to install a full client on each? That's a whole lot of redundant data!
Sharing the data directory is entirely possible, but then where do I specify where Armory should look for these?
Have to install a full client on each? That's a whole lot of redundant data!
Sharing the data directory is entirely possible, but then where do I specify where Armory should look for these?
Nope. Armory needs both access to the network (this could work remotely although Armory would need a tweak) and access to the blockchain files (this won't work remotely).
If you really want this. You could maybe do some trickery with something like ssh tunnels for localhost:8333 to your node and maybe a nfs file share to your blockchain files on the node.
If you really want this. You could maybe do some trickery with something like ssh tunnels for localhost:8333 to your node and maybe a nfs file share to your blockchain files on the node.
I want to connect to a bitcoin server I have running on my home network, rather than a local copy... can we specify an IP/hostname:port somewhere to connect to?
Jump to: