Dedicated Relay Networks
As discussed earlier, miners increase their advantage in the network by (1) receiving new blocks as fast as possible and (2) broadcasting the mined blocks as fast as possible to the majority of the other miners. Clearly, the time to download and process new blocks is of crucial importance, since miners risk losing their profits when, for example, mining on outdated blocks.
Since the Bitcoin P2P overlay network is a general-purpose broadcast mechanism connecting full Bitcoin nodes, SPV clients, and miners, this network is not necessarily optimized to efficiently circulate blocks across miners. This motivated the rise of a number of private peering network and alternative relay networks  whose sole goal is to connect the miners using high-speed connections in order to ensure a fast broadcast of blocks to miners. These networks  aim to provide transaction and block information faster than the official Bitcoin P2P network (e.g., with latencies in the order of 100 - 3000 milliseconds).
Matt Corallo's relay network is one of the most prominent instantiation of an alternative relay network, currently operating five relay nodes—each serving between 20 and 40 clients. Corallo’s network performs partial object validation and does not follow the request management system of Bitcoin to ensure a faster spread of information in those networks. Given that relay networks are operated by a single entity and only support a limited number of nodes, this allows the operator of these relay networks to control the information fed to the biggest mining pools—and thus to control the entire Bitcoin network.
Note, however, that one can envision alternative relay networks built with different trust models and can incorporate arbitrary policies to counter such centralization; for instance, one can construct a small and trusted decentralized relay network only comprising of representative nodes from each centralized mining pool.
Alert messages were introduced in the Bitcoin client after version 0.3.10. These messages serve to alert the Bitcoin users in case of critical incidents. For example, if a severe vulnerability is found in the Bitcoin client, Bitcoin developers can issue an alert message that will be displayed to the user.
Since alert messages are cryptographically signed, they can only be sent by people that possess the appropriate cryptographic key. Currently, this key is shared among the Bitcoin developers. This gives these entities privileged powers to reach out to users and urge them to adopt a given Bitcoin release. We point out that the current alert payload format supports a RESERVED string that is not currently being used. It is straightforward to see that this field can be abused in the future to send additional control commands (i.e., Botnet-like commands) to be executed by Bitcoin users .