diff options
| author | Matt Corallo <bitcoin-list@bluematt.me> | 2013-11-06 00:50:21 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-11-06 05:50:31 +0000 |
| commit | 854242dcaa41c53cdb151c69ea836e0d7a984437 (patch) | |
| tree | 47d9470fe40609f9be9049ef17f12e47bd5a8591 | |
| parent | 72baa78d05c603e7e611dbac40d41824e2776b59 (diff) | |
| download | pi-bitcoindev-854242dcaa41c53cdb151c69ea836e0d7a984437.tar.gz pi-bitcoindev-854242dcaa41c53cdb151c69ea836e0d7a984437.zip | |
[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
| -rw-r--r-- | 84/c94bdf94ebae7ff7f839d5afc707bedc0b4ac9 | 145 |
1 files changed, 145 insertions, 0 deletions
diff --git a/84/c94bdf94ebae7ff7f839d5afc707bedc0b4ac9 b/84/c94bdf94ebae7ff7f839d5afc707bedc0b4ac9 new file mode 100644 index 000000000..aa0c9508a --- /dev/null +++ b/84/c94bdf94ebae7ff7f839d5afc707bedc0b4ac9 @@ -0,0 +1,145 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <bitcoin-list@bluematt.me>) id 1Vdw0d-0004AD-M7 + for bitcoin-development@lists.sourceforge.net; + Wed, 06 Nov 2013 05:50:31 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bluematt.me + designates 192.241.179.72 as permitted sender) + client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; + helo=mail.bluematt.me; +Received: from mail.bluematt.me ([192.241.179.72]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Vdw0a-0006Iu-Mr + for bitcoin-development@lists.sourceforge.net; + Wed, 06 Nov 2013 05:50:30 +0000 +Received: from [10.232.233.22] (vps.bluematt.me [173.246.101.161]) + by mail.bluematt.me (Postfix) with ESMTPSA id BC0984972B + for <bitcoin-development@lists.sourceforge.net>; + Wed, 6 Nov 2013 05:50:22 +0000 (UTC) +Message-ID: <5279D89D.5000609@bluematt.me> +Date: Wed, 06 Nov 2013 00:50:21 -0500 +From: Matt Corallo <bitcoin-list@bluematt.me> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:24.0) Gecko/20100101 Thunderbird/24.1.0 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +X-Enigmail-Version: 1.6 +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit +X-Spam-Score: -1.5 (-) +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: github.com] + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record + -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain +X-Headers-End: 1Vdw0a-0006Iu-Mr +Subject: [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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 06 Nov 2013 05:50:31 -0000 + +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. + + |