FIBRE is a major upgrade to the Bitcoin Relay Network, both of which were developed and maintained by the hard work and generosity of Matt Corallo. Unlike it’s predecessor, FIBRE is not a network operated by TheBlueMatt but instead is an add-on to Bitcoin Core:
The Fast Internet Bitcoin Relay Engine (FIBRE) codebase is designed as an extension to Bitcoin Core which enables very fast relay with manually selected peers over UDP.
This builds on the Compact Blocks proposal (BIP152) to extend the P2P protocol. A change to the P2P protocol is neither a hard fork nor a soft fork. Instead of affecting block validity, if affects how peers on the network communicate.
One additional improvement in FIBRE is that servers relay individual packets to their peers as soon as they arrive. This way, extra hops do not introduce more latency. Sadly, due to the nature of our FEC encoding, we cannot know if individual packets are a part of a legitimate, or any, block, and thus only enable this optimization between nodes run by the same group.
In other words, optimal FIBRE requires a VPN between miners. Not coincidentally the P2P Encryption proposal (BIP151) establishes the basis for building VPNs in the P2P protocol and explicitly depends on the establishment of node identity:
The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization. Identity authentication will be covered in another BIP and will presume communication encryption after this BIP.
The expectation is that by integrating much of this into the P2P protocol (via BIP151 and BIP152) it will be easier to deploy, resulting in more mining competition.
According to Corallo, work is underway to encourage other parties to create their own FIBRE-based relay networks – an effort he said is needed to keep things decentralized.
This expects that miners will be joined together in VPNs, which of course means miners must exclude other miners who are not in their cartel. So the hope is that there will be multiple competing mining cartels.
TheBlueMatt should certainly extricate himself from control over the relay network, which FIBRE accomplishes. However the decentralized replacement is a well-intended but economically flawed solution. The larger cartel will be more profitable, driving the others out of business or into its arms. Ultimately faster relay is not a solution to the lack of mining decentralization. The advantage to larger hash power must be reduced to the point where factors other than block latency dominate profit.
Clearly only approved parties can connect to a cartel’s private Bitcoin network. This list of approved parties may include payment processors, exchanges, and web wallets. The boundary between this private network and the anonymous public necessarily constitutes a firewall. The cartel will censor transactions; censorship is the point of a firewall. Whether it desires this outcome is irrelevant to Bitcoin security, it will ultimately be decided by the stroke of a pen.
Bitcoin must be a distributed anonymous public network. Its blockchain and mempool are a cache of public information. The P2P protocol is a means for an anonymous party to relay that information to another, including miners. I believe the effort to introduce encryption and therefore identity into the P2P protocol is dangerously misguided. It may accelerate the evolution of Bitcoin to a private network while not actually resolving any privacy or security failings.
Once every node can easily establish an identity, how long will it be before major economic nodes require it of their peers? This could easily flow from exchanges, payment processors and web wallets to their peers as an obvious requirement of KYC/AML. How long before anonymous nodes cannot find peers with welcoming ports and a path through the firewall? How long before anonymous transactions cannot penetrate the firewall?
This is fundamentally the same problem as the optional client supplied identification of the Out of Band Address Exchange using Payment Protocol Encryption proposal (BIP75). BIP151 does not work without node identity and, despite being optional, node identity is, “an extremely undesirable feature to be baking into standards.”