<p>The Bitcoin.org client can be launched with the -connect= parameter.</p>

<p>Simply have it connect to another local node and no outside connectivity occurs.</p>

<p>But once it is caught up to the latest block, the amount of bandwidth is relatively trivial.  There's no reason to do this to save bandwidth once a node has been brought current.</p>

CC BY-SA 3.0
2012-11-20T17:32:52.120Z
Would there be any merit to an automatic discovery and download? Or would it be better to rely on communication among users about the availability of other nodes on the same network? An example I see is a college network, where nodes are likely to exist but be unknown, as opposed to a home network, where a user will know if they are running Bitcoin on another computer.
Colin Dean
CC BY-SA 3.0
2012-11-23T08:13:16.340Z
Bitcoin is a financial app (i.e., money is involved.  As such, you don't cut corners.)  A node is best secured when run in a manner in which it gets blocks from randomly selected peers.  This approach does cause performance that is less than you can get if you manually connect to other local nodes but you would only do so if you trusted those nodes.  In a college environment, you would not want to trust getting all your blocks from peers within that network.
 Again, security is of greater importance than efficient use of bandwidth.
Stephen Gornick
CC BY-SA 3.0
2012-11-23T22:04:44.767Z
That's an excellent point that I had not considered, that security trumps efficiency. However, given the nature of the blockchain, how difficult would it be for a malicious peer to distribute a fake blockchain if our  client would eventually contact the outside world for updates, or even an initial portion of the blockchain?
Colin Dean
CC BY-SA 3.0
2012-11-19T21:03:28.177Z
2012-11-19T21:03:28.177Z
Stephen Gornick
<p>Usually, when a full Bitcoin client such as bitcoind, Bitcoin-QT, or Multibit start on a fresh installation, they connect "to the network" to download the blockchain. If someone has multiple computers or devices, they could end up downloading the whole blockchain several times. This puts a lot of stress on their connection and extra clients on the network that could get their data locally.</p>

<p><strong>Have any clients implemented a standardized way to exchange blockchain data locally, without going over the Internet?</strong></p>

<p>I imagine this would work something like how BitTorrent local peer discovery works, where two clients on the same subnet discover each other through multicast groups and then negotiate transfer of data.</p>

<blockchain><peer-discovery>
Can any Bitcoin client do local peer discovery and blockchain synchronization?
Colin Dean
# Can any Bitcoin client do local peer discovery and blockchain synchronization?

(Asked by: username_0 on 2012-11-19)

Usually, when a full Bitcoin client such as bitcoind, Bitcoin-QT, or Multibit start on a fresh installation, they connect "to the network" to download the blockchain. If someone has multiple computers or devices, they could end up downloading the whole blockchain several times. This puts a lot of stress on their connection and extra clients on the network that could get their data locally.

**Have any clients implemented a standardized way to exchange blockchain data locally, without going over the Internet?**

I imagine this would work something like how BitTorrent local peer discovery works, where two clients on the same subnet discover each other through multicast groups and then negotiate transfer of data.

**Tags:** blockchain, peer-discovery


---

## 1 answers

### Answer by username_1 on 2012-11-19. Score: 6 | Accepted answer

The Bitcoin.org client can be launched with the -connect= parameter.

Simply have it connect to another local node and no outside connectivity occurs.

But once it is caught up to the latest block, the amount of bandwidth is relatively trivial. There's no reason to do this to save bandwidth once a node has been brought current.

> **Comments:**
> **username_0**: Would there be any merit to an automatic discovery and download? Or would it be better to rely on communication among users about the availability of other nodes on the same network? An example I see is a college network, where nodes are likely to exist but be unknown, as opposed to a home network, where a user will know if they are running Bitcoin on another computer.  
> **username_1**: Bitcoin is a financial app (i.e., money is involved.  As such, you don't cut corners.)  A node is best secured when run in a manner in which it gets blocks from randomly selected peers.  This approach does cause performance that is less than you can get if you manually connect to other local nodes but you would only do so if you trusted those nodes.  In a college environment, you would not want to trust getting all your blocks from peers within that network.  Again, security is of greater importance than efficient use of bandwidth.  
> **username_0**: That's an excellent point that I had not considered, that security trumps efficiency. However, given the nature of the blockchain, how difficult would it be for a malicious peer to distribute a fake blockchain if our  client would eventually contact the outside world for updates, or even an initial portion of the blockchain?  

---

