From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rdhjb-0002DQ-I8 for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:26:55 +0000 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; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Rdhja-0004b2-N6 for bitcoin-development@lists.sourceforge.net; Thu, 22 Dec 2011 12:26:55 +0000 Received: by werm13 with SMTP id m13so4963462wer.34 for ; Thu, 22 Dec 2011 04:26:48 -0800 (PST) Received: by 10.216.131.76 with SMTP id l54mr5788938wei.34.1324556808516; Thu, 22 Dec 2011 04:26:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.159.201 with HTTP; Thu, 22 Dec 2011 04:26:07 -0800 (PST) In-Reply-To: <1324556083.30850.13.camel@mei> References: <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 Date: Thu, 22 Dec 2011 13:26:07 +0100 Message-ID: To: Joel Joonatan Kaartinen Content-Type: multipart/alternative; boundary=0016e6d589ec0e740b04b4ad6a00 X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -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: 1Rdhja-0004b2-N6 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Protocol extensions 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, 22 Dec 2011 12:26:55 -0000 --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.

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? =A0Joining the network as a node is very low = cost to
> the other nodes. =A0You can't force any node not to be lazy, since= their option
> is to disconnect themselves. =A0As 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.<= br>
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 othe= r
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--0016e6d589ec0e740b04b4ad6a00--