This information is out-of-date, please see the new FIBRE-based relay network page, instead.

The Bitcoin Relay Network is a system of peering between nodes in
the network by creating a system of high-speed relay nodes for miners
and merchants/exchanges. This system a) acts as a fallback in the
case that the public Bitcoin network encounters issues and b) decreases
block propagation times between miners.
It is NOT designed to in any way replace or decrease the need for the
public Bitcoin P2P network. It is NOT any kind of attempt at
centralization, and I still encourage interested parties to establish
their own private peering agreements with large miners as needed.

The Bitcoin Relay Network consists of a few nodes scattered around
the globe, all of which peer with each other. In order to participate
you should simply run the local client (it will automatically select the server
closest to you).

The current relay nodes can be found at (note that several nodes have several cnames, also see map below)
Note that two nodes (Singapore and Siberia) are relay-only and are not available to end-users.
public.us-west.relay.mattcorallo.com
public.us-east.relay.mattcorallo.com
public.eu.relay.mattcorallo.com
public.jpy.relay.mattcorallo.com
public.bjs.relay.mattcorallo.com
public.{sgp,au,hk}.relay.mattcorallo.com

Some details:
 * The relay nodes do some data verification to prevent DoS, but in
order to keep relay fast, they do not fully verify the data they are
relaying, thus YOU SHOULD NEVER mine a block building on top of a
relayed block without fully checking it with your own bitcoin validator
(as you would any other block relayed from the P2P network).
 * The relay nodes do not follow the standard inv-getdata-tx/block flow,
but instead relay transactions/blocks immediately after they have done
their cursory verification. They do keep some track of whether or not
your nodes claim to have seen the transactions/blocks before relaying,
but you may see transactions/blocks being sent which you already have
and have not requested, if this is a problem for you due to bandwith
issues, you should reconsider your bandwith constraints and/or are
peering with too many nodes.
 * The relay nodes will all relay among themselves very quickly, so
there is no advantage to peering with as many relay nodes as you can
find, in fact, the increased incoming bandwidth during block relay
spikes may result in higher latency for your nodes.
 * The relay nodes are NOT designed to ensure that you never miss data,
and may fail to relay some transactions/blocks. The relay nodes are NOT a
replacement for having peers on the standard P2P network, nor should you
rely on it as your only fast block relay method.
 * Information about when blocks are received is made available publicly
on the stats page. The source of blocks (client's IP address) is logged
and used only privately to optimize the network. Information about when
transactions are received and the source is not logged, though individual
clients may keep logs about the time they received transactions from the
network.

For some time I was asking large miners/merchants to request tokens which
would be used in the case of DoS to switch some entities to private nodes,
however I have largely stopped this practice. If a DoS attack does occur,
expect me to nullroute packets from hosts which have never been the first
to provide a block to the network.

You can find the source for the relay nodes at
https://github.com/TheBlueMatt/RelayNode

1. May 26th: The old network remains largely unmaintained, but a new version based on a fresh codebase is being spun up. Stay tuned
2. November 11th: Major client and server upgrades. Months-old versions are now being dropped entirely and compression ratios should go up a bunch.
3. October 21st: Fixed a bug which allowed connections to get into a state where the server would not realize they have been disconnected, triggering the one-connection-per-IP limit and disallowing connections from some (see https://github.com/TheBlueMatt/RelayNode/commit/9b326ec071dd03be74d2496f251b6ac76596ab1d).
4. September 16th: New topology is now active, but having some issues with GFW. New HK node is thus not yet available to connect to as it might have to move again. Got a new IP for the HK server, which seems to have fixed the GFW issues, so it has been enabled and the stats have been reset and reenabled.
5. September 15th: DigitalOcean Singapore's generally shitty service finally pissed me off enough and I destroyed that server when it went down yet again. Waiting on a new Hong Kong server to be provisioned from a new provider and switched to a different host in Singapore which has much better routing and will be used as a hop-only node (ie be used for transit and will not be connectable by clients). Stats are broken but the rest of the network should generally not have any problems.
6. July 21st: Was recommended a cheaper node in Tokyo, so that switched again, hopefully for the last time.
7. July 20th: Switched to a more expensive node in Tokyo which has much better peering (please consider donating), and spun up a server in Beijing provided by f2pool.
8. July 17th: Seed server killed by host. Resolved now, waiting on blockchain sync before transactions are broadcasted within the network and compression works again. Fixed now.
9. July 8th: Things seem to be running much better now after lots of rewriting. Update your clients for some bugfixes. Those with non-standard transaction acceptance policies should check back over the next few days for some updated operating instructions which will make your relays more effecient.
10. July 8th: New node added (Tokyo, Japan). New hostname (bjs) for possible future Beijing node.
11. July 6th: There are some issues with the relay network due to larger transaction volumes which require rewriting transaction relaying in the network
12. June 18th: Several client updates which improve performance significantly
13. Added privacy notes to the details section below
14. An anonymized snapshot of propogation stats can be found here