articles/using-alternative-p2p-networks-with-bitcoin-core.html

<!--

jon atack

-->
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>jon atack - Using Alternative P2P Networks with Bitcoin Core (and More)</title>
    <meta charset="utf-8">
    <base target="_blank">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" type="text/css" href="/style.css" />
    <script defer src="../script.js"></script>
  </head>

  <body>
    <div id="dark-mode-toggle">
      <label>
        <input type="checkbox" id="darkModeSwitch" />
        <span>Dark Mode</span>
      </label>
    </div>
    <div id="content">
      <div id="right">
        <div class="list">
          <ul>
            <li>
              <a href="/" target="_self">home</a>
            </li>
            <li>
              <a href="/articles" target="_self">articles</a>
            </li>
            <li>
              <a href="/bitcoin.pdf" target="_self">bitcoin white paper</a>
            </li>
            <li>
              <a href="/contact" target="_self">contact</a>
            </li>
            <li>
              <a href="/donate" target="_self">donate</a>
            </li>
            <li>
              &nbsp;
            </li>
            <li class="small">
              style:<br>
              <a href="https://basicbitch.software" class="small" target="_blank">basicbitch.software</a>
            </li>
          </ul>
        </div>
        <div class="namecap">
          <a href="/" target="_self">&nbsp;jon&nbsp;<br>atack</a>
        </div>
      </div>

      <div id="entry_block">
        <div class="entry">
          <div class="date">Last updated: 24 June 2024</div>
          <div class="body">
            <article>
              <div class="title">
                Using Alternative P2P Networks with your Bitcoin Core Node (and more)
              </div>

              <h3 id="summary">Summary — Adopting Bitcoin, San Salvador, November 2022</h3>

              <p>
                We'll discuss why and how to easily use alternative peer-to-peer
                networks (I2P, CJDNS) with your Bitcoin Core node for improved
                network connectivity and robustness — and more good stuff.
              </p>

              <h3 id="i2p">What is I2P?</h3>

              <p>
                <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md"
                   target="_blank" rel="nofollow">I2P</a>
                (the Invisible Internet Project) is an anonymizing network,
                offering a simple layer that identity-sensitive applications can
                use to securely communicate.  All data is wrapped with several
                layers of encryption, and the network is both distributed and
                dynamic, with no trusted parties.  I2P uses
                <a href="https://geti2p.net/en/docs/how/garlic-routing"
                   target="_blank" rel="nofollow">garlic</a>
                routing, bundling and encryption.  See
                <a href="https://geti2p.net/en/docs/how/threat-model"
                   target="_blank" rel="nofollow">here</a>
                for more about its threat model.  Two good blog posts that
                describe I2P and how it compares to Tor are:
                <ul>
                  <li>
                    <a href="https://becomesovran.com/blog/i2p-the-private-layer-of-the-web.html"
                       target="_blank"
                       rel="nofollow">I2P: The Private Layer of the Web</a>
                       (November 2022)
                  </li>
                  <li>
                    <a href="https://www.cloudwards.net/i2p-vs-tor/"
                       target="_blank"
                       rel="nofollow">I2P vs Tor: Online Anonymity Explained &
                      Compared for 2023</a>
                    (February 2023)
                  </li>
                </ul>
              </p>
              <p>
                I2P support was merged into Bitcoin Core v22 in
                <a href="https://github.com/bitcoin/bitcoin/pull/20685"
                   target="_blank" rel="nofollow">PR 20685</a>
                and the documentation is
                <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md"
                   target="_blank" rel="nofollow">here</a>.
              </p>

              <h3 id="cjdns">What is CJDNS?</h3>

              <p>
                <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/cjdns.md"
                   target="_blank" rel="nofollow">CJDNS</a>
                is an IPv6 overlay network that uses public-key cryptography
                for address allocation and a distributed hash table for routing.
                It builds an end-to-end encrypted mesh network over the
                <code>fc00::/8</code> address space (reserved IPv6 range) with a
                friend-of-a-friend network topology.  It is like a distributed,
                shared VPN with multiple entry points where every participant
                can reach any other participant.
              </p>
              <p>
                CJDNS support was merged into Bitcoin Core v23 in
                <a href="https://github.com/bitcoin/bitcoin/pull/23077"
                   target="_blank" rel="nofollow">PR 23077</a>
                and the documentation is
                <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/cjdns.md"
                   target="_blank" rel="nofollow">here</a>.
              </p>

              <h3 id="i2p-and-cjdns-commonalities">I2P and CJDNS commonalities</h3>

              <p>
                Compared to IPv4/IPv6, both I2P and CJDNS provide end-to-end
                encryption and may help protect nodes from traffic analysis and
                filtering.
              </p>

              <p>
                Used with Tor, the I2P and CJDNS networks are complementary,
                less-centralized options that can enhance network redundancy and
                robustness for both your node and the Bitcoin network.
              </p>
              <p>
                Unlike Tor, I2P and CJDNS connections have a source
                address — you can be certain that the peer that connects to you
                from a given address possesses the private key corresponding to
                that address.  This quality can be used to whitelist friend
                nodes.  It is a stronger guarantee than IP addresses (which can be
                spoofed by your ISP, for instance).
              </p>

              <br>

              <h3 id="why-use-multiple-bitcoin-p2p-networks">Why use multiple Bitcoin peer-to-peer networks?</h3>

              <p>
                Using multiple networks provides potentially better
                decentralization, network robustness and censorship
                resistance, e.g. I2P or CJDNS may be operational when Tor is not
                or has degraded operation, while not degrading privacy or
                facilitating fingerprinting compared to running Tor alone.
              </p>
              <p>
                Each network has different characteristics. For instance, Tor is
                widely used but centralized due to its hardcoded
                <a href="https://metrics.torproject.org/rs.html#search/flag:authority"
                   target="_blank" rel="nofollow">directory servers</a>
                /
                <a href="https://consensus-health.torproject.org/"
                   target="_blank" rel="nofollow">consensus nodes</a>
                that store the identity of nodes on the network, which can lead
                to problems (consensus node attacks, denial of service attacks,
                censorship, etc).  At the time of this writing, various forms of
                DoS have been ongoing for nearly half a year now — see
                <a href="https://status.torproject.org/issues/"
                   target="_blank" rel="nofollow">https://status.torproject.org/issues</a>.
              </p>
              <p>
                I2P can be fairly slow in latency (similar to Tor), and unlike
                Tor, connections have a source address.  However, starting with
                24.0 containing the merge of
                <a href="https://github.com/bitcoin/bitcoin/pull/25355"
                   target="_blank" rel="nofollow">PR 25355</a>,
                Bitcoin Core automatically generates a new transient
                address for every outbound I2P peer connection when I2P
                listening is turned off, i.e. when your node doesn't accept
                inbound I2P connections by using the configuration option
                <code>-i2pacceptincoming=0</code>. (Note that turning off
                listening is neither the default behavior nor necessarily
                recommended.)
             </p>
              <p>
                CJDNS is generally quite fast but does not hide the sender and
                the recipient from intermediate routers; it was designed to be
                used with a friend-of-a-friend topology.  It builds an overlay
                network which traverses NAT (Network Address Translation),
                exposing all ports of every node to every other node within the
                network.  Those who are used to relying on NAT to protect their
                devices may find this troublesome.
              </p>
              <p>
                Overall, it is good to have options and redundancy.  I've found
                both I2P and CJDNS work very well for my nodes alongside Tor,
                and they generally are the first peer connections that I see on
                node startup.
              </p>
              <p>
                A question that sometimes comes up is whether running your
                node over multiple networks means that it will gossip to all
                of the networks you have set up.  The answer is (generally)
                yes, depending on your configuration. For example, most
                full nodes are configured to relay new transactions to all
                of their peers unless they’ve already received an
                advertisement about the transaction from that peer.
              </p>

              <br>

              <h3 id="considerations-with-running-tor-only">Considerations with running Tor only</h3>

              <p>
                There are security considerations with running a node only over
                Tor, i.e. <code>-onlynet=onion</code> with no other onlynet
                options set.
              </p>
              <ul>
                <li>
                  Sybil/Eclipse attacks:  If you only make random Tor
                  connections, you're much more vulnerable to Sybil attacks. As
                  Tor addresses may be created at no cost, an attacker can
                  potentially flood the network with many Tor nodes and take all
                  of your node's outbound connection slots.  If all of your
                  connections are controlled by a Sybil attacker, they can
                  prevent you from seeing confirmed transactions and, with more
                  difficulty, even trick your node into falsely reporting a
                  transaction as confirmed on the blockchain with the most
                  cumulative chainwork.
                  <p>
                    This can be alleviated by making manual connections to
                    trusted peers using the <code>addnode</code> configuration
                    option or RPC, as a connection to a single honest peer is
                    enough to thwart an attempted eclipse attack.  (It can also
                    be alleviated with IPv4/IPv6 connections — particularly when
                    using the <code>-asmap</code> configuration option — due to
                    the cost of obtaining IPs in many networks.)
                  </p>
                </li>
                <li>
                  Network Partitioning:  If a sufficiently large proportion of
                  Tor nodes uses <code>-onlynet=onion</code> without setting
                  other onlynet options, it could become difficult for onion
                  nodes to communicate with clearnet, I2P, and CJDNS nodes,
                  preventing the Tor network from seeing recent transactions and
                  blocks.
                  <p>
                    The same is even more true for nodes running only I2P
                    or CJDNS.  It is essential that some nodes access multiple
                    networks, and with the currently small identity set of
                    Bitcoin nodes that run I2P or CJDNS it is a good idea for a
                    node to run these as one of several networks.  Initial Block
                    Download (IBD) will be much faster as well.
                  </p>
                </li>
              </ul>

              <h3 id="bitcoin-core-listening-port">Bitcoin Core Listening Port</h3>

              <p>
                Historically, the network listening port on mainnet has been
                8333; Bitcoin Core had a strong preference for only connecting
                to nodes on clearnet that listen on that port.
              </p>
              <p>
                Since Bitcoin Core 23.0, that preference was removed with the
                merge of
                <a href="https://github.com/bitcoin/bitcoin/pull/23542"
                   target="_blank" rel="nofollow">PR 23542</a>,
                because connections over clearnet involving port 8333 make it
                easy to detect, analyze, block or divert Bitcoin P2P traffic
                before the connection is even established (at TCP SYN time).
                Your Bitcoin Core node may now use any port, so consider using a
                different one over clearnet, and/or running it behind a VPN
                to encrypt your node's traffic.
              </p>

              <br>

              <h3 id="getting-started">Getting Started</h3>

              <p>
                Running your Bitcoin Core node over I2P and CJDNS is
                surprisingly quick and easy.  Here is the Bitcoin Core
                documentation for running your node with:
                <ul>
                  <li>
                    <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md"
                       target="_blank" rel="nofollow">Tor</a>
                  </li>
                  <li>
                    <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md"
                       target="_blank" rel="nofollow">I2P</a>
                  </li>
                  <li>
                    <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/cjdns.md"
                       target="_blank" rel="nofollow">CJDNS</a>
                  </li>
                </ul>
                In many cases, getting started with I2P could be as quick as:
                <ul>
                  <li>
                    Install i2pd (I2P daemon) on the command line:<br>
                    <code>apt install i2pd && systemctl enable i2pd.service && systemctl start i2pd.service</code> (Linux), or<br>
                    <code>brew install i2pd && brew services start i2pd</code> (macOS)
                  </li>
                  <li>
                    Add these options to your <code>bitcoin.conf</code>
                    configuration file (on Linux it is usually located in the
                    <code>~/.bitcoin/</code> directory, and on macOS in
                    <code>~/Library/Application\ Support/Bitcoin</code>):<br>
                    <code>i2psam=127.0.0.1:7656</code><br>
                    <code>debug=i2p</code> (to turn on I2P logging in the debug log)
                  </li>
                  <li>
                    Restart your node with Bitcoin Core version 22 and up.
                  </li>
                </ul>
              </p>
              <p>
                To bootstrap your node's peer connections, if you need peers
                running I2P, CJDNS or Tor to manually connect to (using
                the <code>addnode</code> configuration option or RPC), you
                can find some in the Bitcoin Core source code file
                <a href="https://github.com/bitcoin/bitcoin/blob/master/contrib/seeds/nodes_main_manual.txt"
                   target="_blank"
                   rel="nofollow">contrib/seeds/nodes_main_manual.txt</a>.
              </p>

              <br>

              <h4 id="cjdns-peers">CJDNS Peers</h3>

              <p>
                There aren't many Bitcoin nodes running CJDNS yet, so here are
                some CJDNS peers you can connect your node to:
                <ul>
                  <li>
                    fcc7:be49:ccd1:dc91:3125:f0da:457d:8ce
                  </li>
                  <li>
                    fc32:17ea:e415:c3bf:9808:149d:b5a2:c9aa
                  </li>
                  <li>
                    fcd1:c209:bc03:1a75:80d8:2838:a1f1:48c4
                  </li>
                  <li>
                    fc6d:f562:86a0:791d:8a20:7aa2:8879:2176
                  </li>
                  <li>
                    fc70:704d:b268:cdbf:d622:ea9f:db12:859e
                  </li>
                </ul>
              </p>

              <br>

              <h3 id="troubleshooting-your-i2p-service">Troubleshooting your I2P service</h3>
              <p>
                Some steps to try if your node isn't seeing I2P peer
                connections, or if the debug log is showing connection errors
                (please also refer to the
                <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md"
                   target="_blank" rel="nofollow">I2P documentation</a>
                in Bitcoin Core):
                <ul>
                  <li>
                    Restart your I2P router
                  </li>
                  <li>
                    Upgrade your I2P router regularly to the latest version;
                    this can mitigate some connection issues
                  </li>
                  <li>
                    Verify the settings in your <code>bitcoin.conf</code> file
                    and in your I2P router's configuration file
                  </li>
                  <li>
                    Consider changing your router to
                    <a href="https://github.com/PurpleI2P/i2pd"
                       target="_blank" rel="nofollow">i2pd</a>
                    (<a href="https://i2pd.readthedocs.io/en/latest"
                       target="_blank" rel="nofollow">docs</a>)
                    or to
                    <a href="https://geti2p.net"
                       target="_blank" rel="nofollow">i2prouter</a>
                  </li>
                </ul>
              </p>

              <br>

              <h3 id="monitoring-your-node">Monitoring your Bitcoin Core node from the command line</h3>
              <p>
                I generally have the following 3 command line windows open:
                <ul>
                  <li>
                    1 window for the debug log
                  </li>
                  <li>
                    1 window with a live CLI -getinfo dashboard:
                    <p>
                      <code>$ watch --no-title --interval 10 ./src/bitcoin-cli -rpcwait -getinfo</code>
                    </p>
                  </li>
                  <li>
                    1 window with a live CLI -netinfo (network connections) dashboard:
                    <p>
                      <code>$ watch --no-title --interval 4 ./src/bitcoin-cli -rpcwait -netinfo 4</code>
                    </p>
                  </li>
                  <li>
                    Run the following for -netinfo help:
                    <p>
                      <code>$ ./src/bitcoin-cli -netinfo help</code>
                    </p>
                  </li>
                  <li>
                    To see the number of peers your node knows by network type
                    that were active in the past month:
                    <p>
                      <code>$ ./src/bitcoin-cli -rpcwait -addrinfo</code>
                    </p>
                  </li>
                </ul>
              </p>

              Info about the <code>watch</code> command:
              <ul>
                <li>
                  <code>watch</code> is built into Linux as the watch(1) command
                </li>
                <li>
                  with macOS, <code>watch</code> can be installed using brew,
                  i.e. <code>$ brew install watch</code>
                </li>
                <li>
                  adjust the <code>--interval</code> (in seconds) and
                  <code>--no-title</code> arguments as you prefer
                </li>
              </ul>

              <br>
              <p>
                -----
              </p>
              <p>
                Credit to
                <a href="https://github.com/vasild"
                   target="_blank" rel="nofollow">Vasil Dimov</a>
                and
                <a href="https://github.com/Rspigler"
                   target="_blank" rel="nofollow">Robert Spigler</a>,
                as well as to the I2P and CJDNS online documentation and the
                <a href="https://bitcoinops.org/en/topics/" target="_blank"
                   rel="nofollow">Bitcoin Optech topics</a>
                resource, for parts of the text above.
              </p>
              <p>
                Thanks to Vasil Dimov for giving feedback on this article and
                for his amazing work over the years on these areas of Bitcoin
                Core.
              </p>
              <p>
                -----
              </p>
              <p>
                Jon has been contributing to Bitcoin Core development since
                early 2019 with decentralization, censorship resistance,
                robustness, and privacy being his highest priorities.
                He helps onboard new contributors through mentoring and with
                his writing at
                <a href="https://jonatack.github.io/articles" target="_blank"
                   rel="nofollow">https://jonatack.github.io/articles</a>.
              </p>
            </article>
          </div>
        </div>
      </div>
    </div>
  </body>
</html>