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
177
178
179
180
181
182
183
184
185
186
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1Rdenu-00030L-RI
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 09:19:10 +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 1Rdeno-0000n4-Et
for bitcoin-development@lists.sourceforge.net;
Thu, 22 Dec 2011 09:19:10 +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 pBM9IrIY020551
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Thu, 22 Dec 2011 10:18:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
Date: Thu, 22 Dec 2011 10:18:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <84C7327F-4149-4F69-8D7A-F5B3BBE96FA4@ceptacle.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
<4EEE58CA.5090902@justmoon.de>
<67FAA76C-1734-471D-A3D8-31E5216DD512@ceptacle.com>
<CABr1YTdUQeAuw2vwZS=VvDU1dTrN+eqjHRXMsZp2axcxbTsO8A@mail.gmail.com>
<028C9CB5-A7C9-4042-BC00-269046E2DD19@ceptacle.com>
<CALxbBHW4v2FohtaFi0MRey5RoBQodEK5kPsGCAv5xVmmDOOjZQ@mail.gmail.com>
To: Christian Decker <decker.christian@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: 1Rdeno-0000n4-Et
Cc: Bitcoin Dev <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 09:19:10 -0000
>=20
> As for the DHT we had a few brainstorming sessions a while back on the =
forum http://bit.ly/sc2RLZ (gmaxwell didn't like it then either :D)
> Forcing someone to participate in a fixed position in the block =
storage network is a good way to reduce the risk of a sybil attack as =
Michael said. The hash should include only information that cannot be =
changed by the user, so IP can be used, but including the port is risky.
Agree, that is why we need to keep the different A.B segment requirement =
as is also imposed in the client today.
>=20
> Broadcasting the transactions would not need to be done, since miners =
fetch them from their storage place, alternatively we could use the inv =
broadcast to notify peers about a new block/transaction and let it =
retrieve them from the permanent storage (DHT or block storage network). =
If we route traffic internally in the DHT we could even start caching at =
nodes leading to the real location, since announcements would lead to =
flashcrowds, putting heavy load on the responsible nodes. Caching is not =
a risk since the hash of the object to be retrieved is already known.
I agree that in practice the thinner nodes would most likely just serve =
as cache, but they need notification on tx'es involving some of their tx =
outs or involving some of theirs bitcoin addresses. Today there are some =
designs that operate with a thin client that connects to a (web)server =
and subscribe to listen for transactions involving a specific bitcoin =
address. By letting that be a part of the hash space including that =
address you would not reveal your address to the server and we would =
keep a true p2p setup.
Best regards,
Michael
>=20
> Regards,
> Chris
>=20
> On Wed, Dec 21, 2011 at 1:41 PM, Michael Gr=F8nager =
<gronager@ceptacle.com> wrote:
> I find it likely that we will at some point have supernodes. If we =
have browser based wallets then the server for these automatically =
becomes supernodes. Further, if we move along that direction, it becomes =
much simpler to use both the scheme I proposed or to use a a lot of =
other schemes for sharing the validation work on a farm constituting the =
supernode.
>=20
> However, if we want to keep bitcoin in a real p2p setup and enable =
scalability in terms of ensuring both thin and fat client to connect =
then we need to go along the path I propose.
>=20
> Actually, after thinking a bit more about the possible new attack =
vector I don't find it that alarming - if you still require 7 =
confirmations of any bigger transaction before you, as receiver accepts =
the transaction as payed you will not risk anything. The question is =
then if it is sufficiently easy to fake small transaction to e.g. gain =
access to micropayment based web services. I would again say no - the =
requirement that you have ok from e.g. 8 different A.B nodes will make =
it extremely difficult to cheat, and that would even require you to gain =
some level of control over the network that the service you want to =
cheat is connected through.
>=20
> This means that you should not divide the hash space more finely than =
you would at all times be able to find 8 different A.B nodes. As the =
number of clients grows you can then divide the hash space further. =
(with 100000 nodes today and a division into 512 parts you would have =
approx 200 nodes to choose from).
>=20
> Cheers,
>=20
> M
>=20
>=20
>=20
> On 21/12/2011, at 12:42, Eric Lombrozo wrote:
>=20
>> Is it just me or does it seem inevitable that at some point =
supernodes
>> will emerge that other nodes trust to validate transactions for them?
>> Supernodes needn't even store the entire block chain and transaction
>> pool...it would be sufficient that they keep lists of IP addresses of
>> other trustworthy nodes and partition them into a hashspace.
>>=20
>> Anonymous peers have no reputation to defend...but a trusted =
supernode
>> would, which could provide just enough incentive for the supernode to
>> do its best to ensure the nodes it vouches for are indeed legit. Of
>> course, unless the supernode is validating the entire block chain and
>> transaction pool itself, it could only assess the trustworthiness of
>> other nodes by performing random sampling.
>>=20
>> Michael, I really like your ideas and the clarity you bring to the
>> issue. Regarding the potential attack vector you mention, would it be
>> possible to partition the hashspace to minimize the risk that an
>> attacker can manage to disproportionately gain control over a part of
>> the hashspace?
>>=20
>> =
--------------------------------------------------------------------------=
----
>> 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
>=20
>=20
>=20
>=20
>=20
> =
--------------------------------------------------------------------------=
----
> 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
>=20
|
