Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ve1Uv-0003kj-3M for bitcoin-development@lists.sourceforge.net; Wed, 06 Nov 2013 11:42:09 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.54 as permitted sender) client-ip=74.125.82.54; envelope-from=jgarzik@bitpay.com; helo=mail-wg0-f54.google.com; Received: from mail-wg0-f54.google.com ([74.125.82.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ve1Ut-0001I9-F3 for bitcoin-development@lists.sourceforge.net; Wed, 06 Nov 2013 11:42:09 +0000 Received: by mail-wg0-f54.google.com with SMTP id c11so4788633wgh.33 for ; Wed, 06 Nov 2013 03:42:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L5l8UDt+ITm24htoctq/rb+qTKsF8yQlMQGlhZhOZug=; b=T17t4cBIsTZNyN9z+xCRm+Og6eBOd+9EDJe4e4ZEjrtX0aMQzzjcTFC6p0Rt85W6Wq Qa5Rr52b2jaHceZ3/pbxmU/UVziyPW7lU+dGZMr1mQZIq7T2a5YbTet9HyJPDtjrSBZo yizSSbdor3DOJbfd7EZnggayjBu7MVpB4hWk7tQYYKRVf0U9XTQJorkrv67vuojaOZXl Ynbv0zlIx5Llzk1UBijgvyJU5kmxBp3dv3Gm5XA6BaXoDKUflo0tMt6B826kfF9ydw3z XaR3kyM4u722+TpSK5c6ml/BGgp8nlYRB9x3VZ4fg/vBcf0BlxlGHy0Omc3LVZrml5kq mpbg== X-Gm-Message-State: ALoCoQkMdNnrCmh88TT5RdU1g/0pRZCrsuBLPM+PY2UfQijreVsepxPmnYgyCJE5cR5J9srJfAqA MIME-Version: 1.0 X-Received: by 10.180.198.5 with SMTP id iy5mr20765146wic.45.1383738121194; Wed, 06 Nov 2013 03:42:01 -0800 (PST) Received: by 10.194.164.164 with HTTP; Wed, 6 Nov 2013 03:42:01 -0800 (PST) Received: by 10.194.164.164 with HTTP; Wed, 6 Nov 2013 03:42:01 -0800 (PST) In-Reply-To: <5279D89D.5000609@bluematt.me> References: <5279D89D.5000609@bluematt.me> Date: Wed, 6 Nov 2013 06:42:01 -0500 Message-ID: From: Jeff Garzik To: Matt Corallo Content-Type: multipart/alternative; boundary=047d7b624e2a2d2e7b04ea80a33a X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ethz.ch] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Ve1Ut-0001I9-F3 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 11:42:09 -0000 --047d7b624e2a2d2e7b04ea80a33a Content-Type: text/plain; charset=ISO-8859-1 Good stuff. I have been pushing for private peering agreeents and a "backbone" for years. Even had a paltry effort going with exmulti.net + a few manually connected parties. I hope parties in the bitcoin space take it upon themselves to network with major sites - miners, payment processors, exchanges, popular sites, etc. On Nov 6, 2013 12:50 AM, "Matt Corallo" wrote: > Recently, there has been a reasonable amount of discussion about the > continued fragility of the public Bitcoin network on IRC and elsewhere > (1). To this extent, I'm organizing 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 will a) act as a fallback in the > case that the public Bitcoin network encounters issues and b) decrease > 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. > > Currently the network consists of one specially-designed relay node, but > I hope to bring more online in the coming days. > > This network is open to everyone via a few public relay nodes, but also > will have nodes which are made available only to large miners and > merchants/exchanges to mitigate the ability of malicious parties to DoS > the network. > > To peer with the public relay nodes, simply select the closest region > out of us-west (West Coast US), us-east (East Coast US), eu (Western > Europe), au (Australia), or jpy (Japan) and add > public.REGION.relay.mattcorallo.com to your addnode list. Note that > since all of the relay nodes will relay between each other, you gain no > latency advantage by peering with more than the closest node to you (and > currently all the regions map to one node, so there they're redundant > anyway). > > For each relay node, you can connect to either port 8334 or 8335. > Connecting on port 8334 will relay only blocks, and port 8335 will relay > both blocks and transactions. The relay nodes will request any > transactions which appear in your invs no matter which port you connect to. > > Relay node 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. Additionally, because the relay > nodes do not respond to standard getdata requests, if you miss a relay > and then reconnect, that data will not be sent again by the relay nodes. > The relay nodes are NOT a replacement for having peers on the standard > P2P network, they are only there to augment the existing P2P network. > > If you are a merchant/exchange/large miner/other important node operator > and wish to gain access to additional domain names which map to relay > nodes with fewer peers, please fill out the form at > > https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform > > You can find the source for the relay nodes at > https://github.com/TheBlueMatt/RelayNode > > If you have any comments/concerns/suggestions, please do not hesitate to > email bitcoin-peering@mattcorallo.com > > Thanks, > Matt > > > (1) There has been extended discussion on #bitcoin-wizards as well as > #bitcoin-dev of the very small number of active, listening nodes. > Additionally, because many of those nodes are versions prior to 0.8.4, > it seems very likely that maliciously creating network splits or at > least drastically reducing the number of peers for most nodes would not > be particularly challenging in the current network. Also, > > http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf > noted that they were able to single-handledly decrease the network-wide > orphan rate by around 50% by improving network peering. Finally, you've > all seen the recent discussion on malicious mining algorithms. Though > those are not entirely prevented by reducing block propagation times, > they can be significantly limited compared to the current, rather > disjoint, network. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7b624e2a2d2e7b04ea80a33a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Good stuff.=A0 I have been pushing for private peering agreeents and a &= quot;backbone" for years. Even had a paltry effort going with exmulti.net + a few manually connected parties.=

I hope parties in the bitcoin space take it upon themselves to network w= ith major sites - miners, payment processors, exchanges, popular sites, etc= .

On Nov 6, 2013 12:50 AM, "Matt Corallo"= ; <bitcoin-list@bluematt.me<= /a>> wrote:
Recently, there has been a reasonable amount of discussion about the
continued fragility of the public Bitcoin network on IRC and elsewhere
(1). To this extent, I'm organizing a system of peering between nodes i= n
the network by creating a system of high-speed relay nodes for miners
and merchants/exchanges. This system will a) act as a fallback in the
case that the public Bitcoin network encounters issues and b) decrease
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.

Currently the network consists of one specially-designed relay node, but I hope to bring more online in the coming days.

This network is open to everyone via a few public relay nodes, but also
will have nodes which are made available only to large miners and
merchants/exchanges to mitigate the ability of malicious parties to DoS
the network.

To peer with the public relay nodes, simply select the closest region
out of us-west (West Coast US), us-east (East Coast US), eu (Western
Europe), au (Australia), or jpy (Japan) and add
pu= blic.REGION.relay.mattcorallo.com to your addnode list. Note that
since all of the relay nodes will relay between each other, you gain no
latency advantage by peering with more than the closest node to you (and currently all the regions map to one node, so there they're redundant anyway).

For each relay node, you can connect to either port 8334 or 8335.
Connecting on port 8334 will relay only blocks, and port 8335 will relay both blocks and transactions. The relay nodes will request any
transactions which appear in your invs no matter which port you connect to.=

Relay node details:
=A0* 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).
=A0* The relay nodes do not follow the standard inv-getdata-tx/block flow,<= br> 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.
=A0* 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.
=A0* The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. Additionally, because the relay nodes do not respond to standard getdata requests, if you miss a relay
and then reconnect, that data will not be sent again by the relay nodes. The relay nodes are NOT a replacement for having peers on the standard
P2P network, they are only there to augment the existing P2P network.

If you are a merchant/exchange/large miner/other important node operator and wish to gain access to additional domain names which map to relay
nodes with fewer peers, please fill out the form at
https://docs.google.com/forms/d/1U= L82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform

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

If you have any comments/concerns/suggestions, please do not hesitate to email bitcoin-peering@ma= ttcorallo.com

Thanks,
Matt


(1) There has been extended discussion on #bitcoin-wizards as well as
#bitcoin-dev of the very small number of active, listening nodes.
Additionally, because many of those nodes are versions prior to 0.8.4,
it seems very likely that maliciously creating network splits or at
least drastically reducing the number of peers for most nodes would not
be particularly challenging in the current network. Also,
http://www.tik.ee.ethz.ch/file/49318d3f5= 6c1d525aabf7fda78b23fc0/P2P2013_041.pdf
noted that they were able to single-handledly decrease the network-wide
orphan rate by around 50% by improving network peering. Finally, you've=
all seen the recent discussion on malicious mining algorithms. Though
those are not entirely prevented by reducing block propagation times,
they can be significantly limited compared to the current, rather
disjoint, network.

---------------------------------------------------------------------------= ---
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explor= e
techniques for threading, error checking, porting, and tuning. Get the most=
from the latest Intel processors and coprocessors. See abstracts and regist= er
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7b624e2a2d2e7b04ea80a33a--