Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VekVt-0008It-Ai for bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 11:46:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.41 as permitted sender) client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f41.google.com; Received: from mail-oa0-f41.google.com ([209.85.219.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VekVr-0003sG-UN for bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 11:46:09 +0000 Received: by mail-oa0-f41.google.com with SMTP id g12so690188oah.14 for ; Fri, 08 Nov 2013 03:46:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr11272958obm.14.1383911162244; Fri, 08 Nov 2013 03:46:02 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Fri, 8 Nov 2013 03:46:02 -0800 (PST) In-Reply-To: <527AD246.9050906@bluematt.me> References: <5279D89D.5000609@bluematt.me> <527AD246.9050906@bluematt.me> Date: Fri, 8 Nov 2013 12:46:02 +0100 X-Google-Sender-Auth: CJ2keeL1lz0jpv7nrq7d6dwFPhE Message-ID: From: Mike Hearn To: Matt Corallo Content-Type: multipart/alternative; boundary=001a11c3235a39f55404eaa8ed32 X-Spam-Score: -0.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: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1VekVr-0003sG-UN 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: Fri, 08 Nov 2013 11:46:09 -0000 --001a11c3235a39f55404eaa8ed32 Content-Type: text/plain; charset=UTF-8 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) 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. 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. On Thu, Nov 7, 2013 at 12:35 AM, Matt Corallo wrote: > No, the transactions relayed are piped through a bitcoind first (ie > fully verified by a bitcoind). For blocks, for which the timing needs to > be tighter, bitcoinj does SPV-validation. Though it is possible to > create a block which passes SPV validation but causes a DoS score, doing > so would cost a miner a full block's worth of profits, which they are > fairly unlikely to do. In any case, if it every becomes a problem, its > not hard to adapt addnode to allow higher DoS scores for individual nodes. > > Matt > > On 11/06/13 07:25, Tier Nolan wrote: > > > > > > > > On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo > > wrote: > > > > 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). > > > > > > Wouldn't this cause disconnects due to misbehavior? > > > > A standard node connecting to a relay node would receive > > blocks/transactions that are not valid in some way and then disconnect. > > > > Have you looked though the official client to find what things are > > considered signs that a peer is hostile? I assume things like double > > spending checks count as misbehavior and can't be quickly checked by a > > relay node. > > > > Maybe another bit could be assigned in the services field as "relay". > > This means that the node doesn't do any checking. > > > > Connects to relay nodes could be command line/config file only. Peers > > wouldn't connect to them. > > > ------------------------------------------------------------------------------ > 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 > --001a11c3235a39f55404eaa8ed32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I took a brief look at the code - it's looking very re= asonable. You can replace any construct like

try {
=
=C2=A0 Thread.sleep(1000);
} catch (InterruptedException e) = {
=C2=A0 throw new RuntimeException(e);
}

=
which is quite verbose, just with Uninterruptibles.sleepUninterruptabl= y(1000, TimeUnit.MILLISECONDS); (and of course static imports help too)

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= 9;t reach out to you.

I still find it perhaps more= elegant to just boost the connectivity of the existing network with bitcoi= nd changes, but this can help for now.



On Thu, Nov 7, 2013 at 12:35 AM, Matt Corallo <= ;bitcoin-list= @bluematt.me> wrote:
No, the transactions relayed are piped throu= gh a bitcoind first (ie
fully verified by a bitcoind). For blocks, for which the timing needs to be tighter, bitcoinj does SPV-validation. Though it is possible to
create a block which passes SPV validation but causes a DoS score, doing so would cost a miner a full block's worth of profits, which they are fairly unlikely to do. In any case, if it every becomes a problem, its
not hard to adapt addnode to allow higher DoS scores for individual nodes.<= br>
Matt

On 11/06/13 07:25, Tier Nolan wrote:
>
>
>
> On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo <bitcoin-list@bluematt.me
> <mailto:bitcoin-list@bluematt.me>> wrote:<= br> >
> =C2=A0 =C2=A0 Relay node details:
> =C2=A0 =C2=A0 =C2=A0* The relay nodes do some data verification to pre= vent DoS, but in
> =C2=A0 =C2=A0 order to keep relay fast, they do not fully verify the d= ata they are
> =C2=A0 =C2=A0 relaying, thus YOU SHOULD NEVER mine a block building on= top of a
> =C2=A0 =C2=A0 relayed block without fully checking it with your own bi= tcoin validator
> =C2=A0 =C2=A0 (as you would any other block relayed from the P2P netwo= rk).
>
>
> Wouldn't this cause disconnects due to misbehavior?
>
> A standard node connecting to a relay node would receive
> blocks/transactions that are not valid in some way and then disconnect= .
>
> Have you looked though the official client to find what things are
> considered signs that a peer is hostile? =C2=A0I assume things like do= uble
> spending checks count as misbehavior and can't be quickly checked = by a
> relay node.
>
> Maybe another bit could be assigned in the services field as "rel= ay".
> This means that the node doesn't do any checking.
>
> Connects to relay nodes could be command line/config file only. =C2=A0= Peers
> wouldn't connect to them.

-----------------------= -------------------------------------------------------
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

--001a11c3235a39f55404eaa8ed32--