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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1RdfsG-0006Mr-AC
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 10:27:44 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RdfsE-0004oD-RC
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 10:27:44 +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 pBMARWnl017746
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 22 Dec 2011 11:27:33 +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: <201112221012.55565.andyparkins@gmail.com>
Date: Thu, 22 Dec 2011 11:27:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <23F92B83-4E96-401B-8A1C-3E6FE9DD8A8B@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
<CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
<201112221012.55565.andyparkins@gmail.com>
To: Andy Parkins <andyparkins@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: 1RdfsE-0004oD-RC
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 10:27:44 -0000
It is analog to getting assigned a random part (based on IP) of the =
hashspace and then only verify transactions within this fraction.
But, there is in fact a subtle difference: If anyone can choose to =
verify at random, you will see lazy implementations where random means =
none, and as it is random you cannot, from the outside, judge if a node =
is taking part in the validation work or if it just benefitting from =
others announcements. In the hash space part, you can monitor peers and =
see if they did not tell you about a failed validation and then =
disconnect from them as they are either malicious or lazy.
Besides from that, I like a setup where we scream about failed =
verifications, but keep a low profile on things that actually =
verifies...
/M
On 22/12/2011, at 11:12, Andy Parkins wrote:
> On 2011 December 21 Wednesday, Christian Decker wrote:
>=20
>> Supernodes will be those nodes that verify all transactions and make =
them
>> available to miners. Since miners will become more and more =
specialized
>> these supernodes are likely to be owned by the miners themself. To be =
a
>> miner either you need to verify all the transactions you include =
(otherwise
>> others might be able to find an error in your block and thus drop it) =
or
>> have someone that verifies them for you. In the end I think we'll end =
up
>> with a hierarchical network, with the miners/supernodes tighly
>> interconnected at the top and the lightweight clients that simply =
verify
>> transactions (or their inputs to be precise) that are destined for =
them at
>> the bottom.
>=20
> A thought occurred to me. We already run a decentralised system, but =
it's=20
> done by making everyone duplicate all other work. There is no =
fundamental=20
> reason why all work needs to be duplicated though. What about this: =
every=20
> node randomly chooses whether to verify any particular transaction. =
If we=20
> assume the network is large and the random factor is correctly chosen, =
then we=20
> can still guarantee that every transaction is verified. Then, we =
simply add a=20
> protocol message that is a negative-announce transaction. That is to =
say, we=20
> give nodes a way of telling other nodes that they think a transaction =
is=20
> invalid. The other nodes are then free to verify _that_ assertion and =
forward=20
> the negative-announce.
>=20
> Miners can then listen for negative-announcements and use them to =
decide were=20
> to dedicate their verification efforts. They then don't need to =
verify all=20
> (or perhaps even any) transactions themselves and can dedicate their=20=
> processing power to mining.
>=20
> (I've actually mentioned this idea before, but that time I was using =
it as a=20
> double-spend prevention method).
>=20
>=20
>=20
> Andy
>=20
> --=20
> Dr Andy Parkins
> andyparkins@gmail.com
|
