Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VgmPH-0001Ed-MO for bitcoin-development@lists.sourceforge.net; Thu, 14 Nov 2013 02:11:43 +0000 Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VgmPG-00055m-UB for bitcoin-development@lists.sourceforge.net; Thu, 14 Nov 2013 02:11:43 +0000 Received: from [10.232.233.22] (vps.bluematt.me [173.246.101.161]) by mail.bluematt.me (Postfix) with ESMTPSA id DF3C148FA3; Thu, 14 Nov 2013 02:11:36 +0000 (UTC) Message-ID: <52843157.9000609@bluematt.me> Date: Wed, 13 Nov 2013 21:11:35 -0500 From: Matt Corallo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mike Hearn References: <5279D89D.5000609@bluematt.me> <527AD246.9050906@bluematt.me> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 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. -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: 1VgmPG-00055m-UB Cc: Bitcoin Dev 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: Thu, 14 Nov 2013 02:11:43 -0000 On 11/08/13 06:46, Mike Hearn wrote: > I took a brief look at the code - it's looking very reasonable. You can > replace any construct like > > try { > Thread.sleep(1000); > } catch (InterruptedException e) { > throw new RuntimeException(e); > } > > which is quite verbose, just with > Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and > of course static imports help too) Thanks, fixed. > > I think for this concept to take off, you'd need a website and to > recruit someone to help you market it. Pool operators won't reach out to > you. Yes, I've done some initial outreach and plan on doing another major round now that the initial network is up and Im working on running some relay time benchmarks. Finding someone to help push peering would be nice, if you have any suggestions, Im all ears. > > I still find it perhaps more elegant to just boost the connectivity of > the existing network with bitcoind changes, but this can help for now. Agreed, improving relay times across the regular P2P network would be nice, however I really dont see this as a part of the P2P network. Its more of a backup relay network that just happens to follow the P2P protocol (mostly, it doesnt do full block verification, so technically it breaks spec). In this model, this is really a nice augment to the P2P network no matter what improvements are made. Having more protocols/ways blocks are relayed is always nice (anyone wanna launch a satellite?) Matt