4 ms·

There are many protocols which are "logically" P2P, but actually using the network in a P2P fashion is a different matter and much more difficult. Hypercore, fo

There are many protocols which are "logically" P2P, but actually using the network in a P2P fashion is a different matter and much more difficult. Hypercore, for example, uses a "distributed hole-punching" architecture in which clients that want to communicate with each other discover each other using a DHT and then preemptively send UDP traffic to each other in order to cause NAT appliances on both ends to create connection tracking entries. Unfortunately this assumes that the DHT is up and running to serve as a "meet-me" point for these nodes to know about each other in the first place. In order for this to happen a DHT member needs to "bootstrap" by... contacting a "bootstrap node" which is basically a special centralized Hyperswarm server with a conventional DNS address and capability to accept inbound connections. This possibly surprising fact, that at the core of the P2P distributed system there is a centralized client-server service that provides the initial discovery information to begin participating, is pretty much universal to P2P systems because of the limitations the internet imposes. Removing this requirement would require a significantly more P2P-architected internet that allowed, for example, participation in arbitrary multicast groups from residential ISPs. There are both theoretical and practical (but mostly practical) challenges to doing this. In other words, the way the internet works, the only real way to begin to participate in a P2P internet protocol is to connect to a centralized service to provide initial peer hints. This is commonly referred to as an "introducer" or "bootstrap node" or "peer helper" or other terms depending on the P2P system. Hypercore and the Hyperswarm P2P network it relies on are actually unusually advanced in how much they minimize the need for an introducer, to the extent that a Hyperswarm node can completely forget about the introducer (it could go down) after initial setup and it will probably continue to work okay although there is a probabilistically small risk of a split-brain scenario. Older P2P protocols like Bittorrent and Tor have a greater dependency on centralized introducers and cannot operate without them even after initial startup (with caveats such as Bittorrent's support for Kademlia DHT, the same underlying DHT protocol used by Hyperswarm, which is in use by some Bittorrent nodes but not all for various reasons). For hypercore specifically the introducers are bootstrap1.hyperdht.org through bootstrap3.hyperdht.org. These are basically hardcoded into your client.

ngcc_hk 5y ago
Not totally true as peer to peer can use a decentralised protocol to find peer. Is there a “centralised” server under Bitcoin? Or is it you can bootstrapping even manually then the peer to peer network can go ahead to find more peer … The problem of “centralisation” is not due to the need of finding peer. It is in the edge. You control the isp you control all. See China. How to break this edge issue … very hard.
- jcrawfordor 5y ago
  > Is there a “centralised” server under Bitcoin? Yes, Bitcoin clients use a semi-hardcoded list of "seed peers" that they look up via DNS and connect to first. Peer discovery proceeds from there using P2P methods. One example is seed.bitcoin.sipa.be, there are several set in the source tree of bitcoin core. Each of these "seed" DNS names provides a list of records that are known good Bitcoin nodes. This DNS method replaced Bitcoin's original method, dating back to Nakamoto, which was to connect to a hardcoded IRC server and then join a hardcoded channel where Bitcoin nodes advertised their presence. There is no real theoretical advantage to the DNS method but it is simpler and DNS is far less likely to be blocked than IRC. As in most distributed/P2P systems, the Bitcoin DNS seeds are somewhat integrity sensitive. Normally the Bitcoin network cannot enter a "split-brain" state (e.g. two independent and equally valid blockchains) because there are a large number of nodes which are strongly interconnected, preventing any substantial number of Bitcoin nodes being unaware of blocks that other nodes are aware of (in actuality Bitcoin enters a "split-brain" state on a regular basis, but as long as nodes are aware of both "valid" blockchains they have an agreed upon convention to select a single blockchain head as valid). But this is only true of nodes which are already participating. When a new Bitcoin node starts for the first time, it has no way to discover any other nodes besides the DNS seeds. In theory, if the DNS seeds were malicious, they could provide a list of nodes which were complicit in an attack by intentionally not forwarding any information about some blocks or advertisements of nodes which are aware of those blocks. In other words, in practice the cost of a sybil attack is actually reduced to the number of nodes directly advertised by the DNS seeds, but only for new users and only if the DNS seeds are complicit. In practice the former is a massive limitation and the Bitcoin project allows only trusted individuals to operate DNS seeds in order to mitigate the latter, so the issue is not that big. The problem is that there actually is no decentralized way to initially discover peers on the internet. Imagine if you wanted to implement a peer-to-peer information flow over the telephone system. If you have a list of telephone numbers of participants you can come up with all kinds of schemes. But what about when you very first join? You don't know any numbers to try. Randomly calling every phone number in order isn't feasible. You need to have some kind of "point of contact" to first discover other peers or you simply have no one to call. There are various terms for this, I like "introducer" but Bitcoin uses "seed" as do some others. Every decentralized system that operates over the internet has a semi-centralized introducer mechanism somewhere deep down. There are several theoretical mechanisms such as multicast groups, but none of these actually work across the internet. They do usually work across local networks (and are used by things like Bonjour), but in the majority of cases when a user wants to bootstrap a P2P system there is no other peer on the same local network.

ngcc_hk 5y ago

Not totally true as peer to peer can use a decentralised protocol to find peer. Is there a “centralised” server under Bitcoin? Or is it you can bootstrapping even manually then the peer to peer network can go ahead to find more peer … The problem of “centralisation” is not due to the need of finding peer. It is in the edge. You control the isp you control all. See China. How to break this edge issue … very hard.

jcrawfordor 5y ago
> Is there a “centralised” server under Bitcoin? Yes, Bitcoin clients use a semi-hardcoded list of "seed peers" that they look up via DNS and connect to first. Peer discovery proceeds from there using P2P methods. One example is seed.bitcoin.sipa.be, there are several set in the source tree of bitcoin core. Each of these "seed" DNS names provides a list of records that are known good Bitcoin nodes. This DNS method replaced Bitcoin's original method, dating back to Nakamoto, which was to connect to a hardcoded IRC server and then join a hardcoded channel where Bitcoin nodes advertised their presence. There is no real theoretical advantage to the DNS method but it is simpler and DNS is far less likely to be blocked than IRC. As in most distributed/P2P systems, the Bitcoin DNS seeds are somewhat integrity sensitive. Normally the Bitcoin network cannot enter a "split-brain" state (e.g. two independent and equally valid blockchains) because there are a large number of nodes which are strongly interconnected, preventing any substantial number of Bitcoin nodes being unaware of blocks that other nodes are aware of (in actuality Bitcoin enters a "split-brain" state on a regular basis, but as long as nodes are aware of both "valid" blockchains they have an agreed upon convention to select a single blockchain head as valid). But this is only true of nodes which are already participating. When a new Bitcoin node starts for the first time, it has no way to discover any other nodes besides the DNS seeds. In theory, if the DNS seeds were malicious, they could provide a list of nodes which were complicit in an attack by intentionally not forwarding any information about some blocks or advertisements of nodes which are aware of those blocks. In other words, in practice the cost of a sybil attack is actually reduced to the number of nodes directly advertised by the DNS seeds, but only for new users and only if the DNS seeds are complicit. In practice the former is a massive limitation and the Bitcoin project allows only trusted individuals to operate DNS seeds in order to mitigate the latter, so the issue is not that big. The problem is that there actually is no decentralized way to initially discover peers on the internet. Imagine if you wanted to implement a peer-to-peer information flow over the telephone system. If you have a list of telephone numbers of participants you can come up with all kinds of schemes. But what about when you very first join? You don't know any numbers to try. Randomly calling every phone number in order isn't feasible. You need to have some kind of "point of contact" to first discover other peers or you simply have no one to call. There are various terms for this, I like "introducer" but Bitcoin uses "seed" as do some others. Every decentralized system that operates over the internet has a semi-centralized introducer mechanism somewhere deep down. There are several theoretical mechanisms such as multicast groups, but none of these actually work across the internet. They do usually work across local networks (and are used by things like Bonjour), but in the majority of cases when a user wants to bootstrap a P2P system there is no other peer on the same local network.