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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <joel.kaartinen@gmail.com>) id 1RdhZS-0000xK-53
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 12:16:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=joel.kaartinen@gmail.com;
helo=mail-lpp01m010-f47.google.com;
Received: from mail-lpp01m010-f47.google.com ([209.85.215.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RdhZO-00044l-77
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 12:16:26 +0000
Received: by lami14 with SMTP id i14so4735938lam.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 22 Dec 2011 04:16:15 -0800 (PST)
Received: by 10.152.145.71 with SMTP id ss7mr7109522lab.28.1324556175644;
Thu, 22 Dec 2011 04:16:15 -0800 (PST)
Received: from [193.199.8.205] (GGZYMMMCCCV.gprs.sl-laajakaista.fi.
[193.199.8.205])
by mx.google.com with ESMTPS id lr3sm7382890lab.17.2011.12.22.04.16.13
(version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 04:16:14 -0800 (PST)
From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
In-Reply-To: <201112221152.38639.andyparkins@gmail.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<201112221012.55565.andyparkins@gmail.com>
<23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com>
<201112221152.38639.andyparkins@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 22 Dec 2011 14:14:43 +0200
Message-ID: <1324556083.30850.13.camel@mei>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.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
(joel.kaartinen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1RdhZO-00044l-77
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:16:26 -0000
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
|
