summaryrefslogtreecommitdiff
path: root/0d/e69e587d163e84299372cc584aaf520a0bb6ac
blob: 999d2e7c3887b1d4f9306350e4ad0cc83ade6163 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
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 <decker.christian@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <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
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: <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: 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.<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--