Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175;
	envelope-from=decker.christian@gmail.com;
	helo=mail-we0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <1324556083.30850.13.camel@mei>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
	<201112221012.55565.andyparkins@gmail.com>
	<23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com>
	<201112221152.38639.andyparkins@gmail.com>
	<1324556083.30850.13.camel@mei>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 22 Dec 2011 13:26:07 +0100
Message-ID: <CALxbBHVjujLfwNEcnm3XLZqeeARkr0N6j2zQgVFodTBeAr5WFw@mail.gmail.com>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6d589ec0e740b04b4ad6a00
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Precedence: list

--0016e6d589ec0e740b04b4ad6a00
Content-Type: text/plain; charset=ISO-8859-1

At first the idea of using negative announces seems attractive, but
remember that a malicious node might trigger verification for every
transaction, which may lead to a DoS.

Regards,
Chris

On Thu, Dec 22, 2011 at 1:14 PM, Joel Joonatan Kaartinen <
joel.kaartinen@gmail.com> wrote:

> On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:
> > Why should they have to?  Joining the network as a node is very low cost
> to
> > the other nodes.  You can't force any node not to be lazy, since their
> option
> > is to disconnect themselves.  As to maliciousness, that is defended
> against
> > because when a node negative announces a transaction, that transaction is
> > going to be checked (note that there is still no implicit trust) -- if a
> node
> > is incorrectly negative-announcing then it can justifiably be kicked.
>
> a node that is not doing any checking themselves can not reliably
> forward failed verifications without getting the blame for doing faulty
> work. Those nodes would then have the incentive not to relay the failed
> verifications. This ends up making it important to know which nodes will
> be checking transactions or not so you don't isolate yourself from other
> nodes that are also checking transactions.
>
> - Joel
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--0016e6d589ec0e740b04b4ad6a00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

At first the idea of using negative announces seems attractive, but remembe=
r that a malicious node might trigger verification for every transaction, w=
hich may lead to a DoS.<br><br>Regards,<br>Chris<br><br><div class=3D"gmail=
_quote">

On Thu, Dec 22, 2011 at 1:14 PM, Joel Joonatan Kaartinen <span dir=3D"ltr">=
&lt;<a href=3D"mailto:joel.kaartinen@gmail.com">joel.kaartinen@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, 2011-12-22 at 11:52 +0000, Andy Parkins wrote:<br=
>
&gt; Why should they have to? =A0Joining the network as a node is very low =
cost to<br>
&gt; the other nodes. =A0You can&#39;t force any node not to be lazy, since=
 their option<br>
&gt; is to disconnect themselves. =A0As to maliciousness, that is defended =
against<br>
&gt; because when a node negative announces a transaction, that transaction=
 is<br>
&gt; going to be checked (note that there is still no implicit trust) -- if=
 a node<br>
&gt; is incorrectly negative-announcing then it can justifiably be kicked.<=
br>
<br>
</div>a node that is not doing any checking themselves can not reliably<br>
forward failed verifications without getting the blame for doing faulty<br>
work. Those nodes would then have the incentive not to relay the failed<br>
verifications. This ends up making it important to know which nodes will<br=
>
be checking transactions or not so you don&#39;t isolate yourself from othe=
r<br>
nodes that are also checking transactions.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Joel<br>
</font></span><div class=3D"im HOEnZb"><br>
<br>
---------------------------------------------------------------------------=
---<br>
Write once. Port to many.<br>
Get the SDK and tools to simplify cross-platform app development. Create<br=
>
new or port existing apps to sell to consumers worldwide. Explore the<br>
Intel AppUpSM program developer opportunity. <a href=3D"http://appdeveloper=
.intel.com/join" target=3D"_blank">appdeveloper.intel.com/join</a><br>
<a href=3D"http://p.sf.net/sfu/intel-appdev" target=3D"_blank">http://p.sf.=
net/sfu/intel-appdev</a><br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>

--0016e6d589ec0e740b04b4ad6a00--