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
|
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 <gronager@ceptacle.com>) id 1Rdhya-0002oA-2n
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 12:42:24 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RdhyV-000581-SW
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 12:42:24 +0000
Received: from [109.105.106.215] ([109.105.106.215]) (authenticated bits=0)
by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBMCg8Qf021163
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 22 Dec 2011 13:42:09 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <1324556083.30850.13.camel@mei>
Date: Thu, 22 Dec 2011 13:42:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E0AD741-A670-469D-9F50-5F1564A0E7C6@ceptacle.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>
<1324556083.30850.13.camel@mei>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RdhyV-000581-SW
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:42:24 -0000
Just adding to Joels comment:
The only one with an incentive to do validations are miners (otherwise =
they could risk having their mined blocks invalidated later by less lazy =
miners) and the ones who are to send and accept a transaction. In a =
distributed stored and validated block chain setup, you would hence need =
to ask some miners if the inputs to a transaction is valid or download =
all the chain yourselves.
The latter is what we do today and will not scale, the former is the =
logical consequence of a non-enforced random validation approach - so =
this will give us super nodes, namely miners, and at some point they =
could choose to also charge for the validations. It might be the =
direction we are moving towards, but then the p2p network is only for =
the miners and the rest of us can connect through https and use json-rpc =
to post transactions etc to them. I do, however, prefer a setup where we =
keep everything really distributed...
/M
On 22/12/2011, at 13:14, Joel Joonatan Kaartinen 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=20
>> the other nodes. You can't force any node not to be lazy, since =
their option=20
>> is to disconnect themselves. As to maliciousness, that is defended =
against=20
>> because when a node negative announces a transaction, that =
transaction is=20
>> going to be checked (note that there is still no implicit trust) -- =
if a node=20
>> is incorrectly negative-announcing then it can justifiably be kicked.
>=20
> 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.
>=20
> - Joel
>=20
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle.com
|
