Week 4 discussion questions

asdf

asdf

The rationale for having two distinct buckets for these different types of connections is that it’s possible that we assume an attacker can gain full control of our inbound slots, by opening multiple connections to us rapidly upon startup, but they can’t control who we make our outbound connections to. It follows that as long as we ensure that we make some outbound connections ourselves that it’s much more difficult for an attacker to eclipse attack us.

In terms of locating the most-work chain tip, we only need to connect to a single honest peer amongst our total connections (8 out and 117 in by default) to have a new most-work header or block relayed to us which we can use to base our chain decision on. In addition to helping us locate the most-work chain tip, a single honest peer can help to repopulate our "address book" — AddrMan (stored in file peers.dat on shutdown) — with honest peers. The first thing we do upon connecting (outbound) to a new peer is to request up to 3 ADDR message(s) containing up to 1000 peers in each message from them. In the case that our AddrMan has previously been "poisoned" (filled with malicious peers) making an outbound connection to a single honest node will help to re-populate AddrMan with honest peers and the rest of the node eviction logic will get rid of malicious peers for us.

The rationale behind the absolute numbers selected for these two types of connections does not seem to be particularly empirical…​ It appears that Satoshi reduced outbound connections from 15 to 8 in July 2010 according to this BitcoinTalk post. The OP in that thread stated the following:

At the time the number of outbound connections was 15, so OP appears to have been servicing ~55 inbounds too. This was likely a side-effect of each peer trying to connect to 15 outbound peers.

Two quotes from Satoshi in reply:

and

In PR 72, "Denial of service flood prevention" by Andresen, the maxconnections parameter was configured to the number 125 we still use by default today in 2021. It is thought, but apparently not measured empirically, that 8 outbounds gives a good balance between having enough that you avoid becoming eclipsed but not so many that the network comes under high strain as usage increases (and particularly at moments where new blocks are found and propagated). Whilst this PR is related to DoS protection, many users around this time were stuggling with their OS and routers handling large numbers of concurrent TCP connections, therefore setting maxconnections to 125 leaves some processing headroom for the average user.

Whilst inbound connections are treated as relatively untrustworthy, their purpose is to allow p2p networking to take place; if everybody can only make outbound connections but nobody accepts inbound connections, then nobody can connect to anybody else! The discrepancy between 8 and 117 might be explained in that we allow for more peers to be "non-listening" (intentionally or behind NAT) or "SPV" to connect to the network, as both of these client modes don’t accept incoming connections. In this way, we allow for ~ 117 / 8 = 14x the number of listening nodes to connect to the network.

If we assume the average user downloads Bitcoin Core GUI on a mid-range Windows laptop and connects to the P2P network via their home access point (possibly behind NAT) then these parameters feel pretty optimum. Those users will maintain their 8 outbounds, 2 blocksonly and possibly get a few inbounds after a while. The liklihood is that their inbounds (someone else’s outbounds) will get dropped due to remote nodes eviction policies as they are likely to not meet eviction criteria (search src/net_processing.cpp for "eviction" to see how this works), and so high numbers of inbounds are unlikely.

Where this might want to be optimised further is for nodes on low-bandwidth connections, although these nodes can run bitcoind with the --blocksonly option or follow other recommendations in /doc/reduce-traffic.md if they are severely constrained.

Additional question: Why were blocksonly connections chosen to be 2 of the 8 outbounds, rather than an additional two connections? A: adding two connections per node might be 100_000 * 2 = 200_000 more outbound connections

asdf

asdf

asdf

asdf

An eclipse attack attempts to prevent one or more nodes on the network from communicating with any honest peers, instead receiving information only from the attackers malicious nodes.

If the eclipsed node was a miner, the most-work chain tip could be delayed or completely withheld from them, resulting in them wasting work mining on a stale tip. If a large-enough % of hash power can be eclipsed simultaneously, say ~30%, then they would start mining a minority fork. A minority fork could be presented to a merchant and used to trick them into accepting a transaction which was double spent (back to the attacker) on the main chain.

A majority 51% attack is extremely expensive to pull off, as it requires significant CAPEX to purchase, setup and operate the required mining hardware, whereas an eclipse attack would require fewer resources, but perhaps more skill, to execute.

asdf

asdf

asdf

asdf

asdf