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
187
188
189
190
191
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1Rc0yD-0008BB-GC
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 20:35:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=decker.christian@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Rc0yC-00061T-Fm
for bitcoin-development@lists.sourceforge.net;
Sat, 17 Dec 2011 20:35:01 +0000
Received: by wgbds1 with SMTP id ds1so7603844wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Sat, 17 Dec 2011 12:34:54 -0800 (PST)
Received: by 10.227.206.10 with SMTP id fs10mr8714609wbb.13.1324154094196;
Sat, 17 Dec 2011 12:34:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.152.10 with HTTP; Sat, 17 Dec 2011 12:34:14 -0800 (PST)
In-Reply-To: <CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com>
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com>
<82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com>
<CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com>
<CAAS2fgRqabDpXBZ7M8BAdzDAsRwFED4BPzoQJkLkwLOeURuXLA@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Sat, 17 Dec 2011 21:34:14 +0100
Message-ID: <CALxbBHWvJwOvnpGjN+A3MpzxrvzFGuJ0JBv6z_zz99Hvs0T+yg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=0015174c103669976804b44fa66d
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: 1Rc0yC-00061T-Fm
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: Sat, 17 Dec 2011 20:35:01 -0000
--0015174c103669976804b44fa66d
Content-Type: text/plain; charset=ISO-8859-1
Criticism accepted, although I'd appreciate it if you supply some reasons
about why it's such a bad idea :-)
The idea was never really popular and before starting work on a real
implementation I wanted to test the water, and should it turn out it's
complete non-sense I'm happy to accept that.
I don't want to have a DHT for the DHTs sake, I was more interested in
reducing the number of messages that need to be sent around the network,
since network load is going to be a major problem if we ever grow beyond a
certain point.
Just wanting to brainstorm.
Regards,
Chris
On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker
> <decker.christian@gmail.com> wrote:
> > My idea was to structure the network in a hypercube and use prefixes to
> > address different parts of the network, and use those prefixes also to
> find
> > the location where an item (transaction, block, ...) should be stored.
> Each
> > vertex in the hypercube is a small, highly connected, cluster of nodes.
>
> I strongly advise people who are not me to use this sort of scheme, so
> that I may enjoy the benefits of robbing you blind.
>
>
> .... But really, saying "some sort of DHT" without basically
> presenting a working implementation that demonstrates the feasibility
> of solving the very difficulty attack resistance problems these
> schemes have basically triggers my time-wasting-idiot filter. (Or
> likewise, presenting a fixed network structure that would have a nice
> small and easily identifiable min-cut...)
>
> I don't doubt I'm completely alone in this, though perhaps I'm more
> of a jerk about it. Even if your actual proposal might have some
> merit you should be aware that every fool who has operated a
> bittorrent client has heard of "DHT" and, although they may not even
> understand what a hash table is, many have no reservation going around
> suggesting them for _every_ distributed systems problem. Want to scale
> matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network
> syncup slow (because It's bound on validation related local IO)? DHT!
> I suggest people solve the real problems first, then worry what name
> to give the solutions. ;)
>
> To address gavin's tragedy of the commons concern, one useful feature
> would being able to mutually authenticate a peer... then full nodes
> could pick and choose which lite nodes they're willing to do (a lot
> of) hard work for. This would also be valuable because some modes of
> lite operation require non-zero trust of the full node being queried.
>
--0015174c103669976804b44fa66d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Criticism accepted, although I'd appreciate it if you supply some reaso=
ns about why it's such a bad idea :-)<br>The idea was never really popu=
lar and before starting work on a real implementation I wanted to test the =
water, and should it turn out it's complete non-sense I'm happy to =
accept that.<br>
<br>I don't want to have a DHT for the DHTs sake, I was more interested=
in reducing the number of messages that need to be sent around the network=
, since network load is going to be a major problem if we ever grow beyond =
a certain point.<br>
<br>Just wanting to brainstorm.<br><br>Regards,<br>Chris<br><div class=3D"g=
mail_quote">On Sat, Dec 17, 2011 at 8:28 PM, Gregory Maxwell <span dir=3D"l=
tr"><<a href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sat, Dec 17, 2011 at 8:=
37 AM, Christian Decker<br>
<<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gmail.co=
m</a>> wrote:<br>
> My idea was to structure the network in a hypercube and use prefixes t=
o<br>
> address different parts of the network, and use those prefixes also to=
find<br>
> the location where an item (transaction, block, ...) should be stored.=
Each<br>
> vertex in the hypercube is a small, highly connected, cluster of nodes=
.<br>
<br>
</div>I strongly advise people who are not me to use this sort of scheme, s=
o<br>
that I may enjoy the benefits of robbing you blind.<br>
<br>
<br>
.... But really, saying "some sort of DHT" without basically<br>
presenting a working implementation that demonstrates the feasibility<br>
of solving the very difficulty attack resistance problems these<br>
schemes have basically triggers my time-wasting-idiot filter. =A0(Or<br>
likewise, presenting a fixed network structure that would have a nice<br>
small and easily identifiable min-cut...)<br>
<br>
I don't doubt I'm completely alone in this, =A0though perhaps I'=
;m more<br>
of a jerk about it. =A0 Even if your actual proposal might have some<br>
merit you should be aware that every fool who has operated a<br>
bittorrent client has heard of "DHT" and, although they may not e=
ven<br>
understand what a hash table is, many have no reservation going around<br>
suggesting them for _every_ distributed systems problem. Want to scale<br>
matrix multiples? DHT! Want to validate bitcoin blocks? DHT! Network<br>
syncup slow (because It's bound on validation related local IO)? DHT!<b=
r>
I suggest people solve the real problems first, then worry what name<br>
to give the solutions. ;)<br>
<br>
To address gavin's tragedy of the commons concern, one useful feature<b=
r>
would being able to mutually authenticate a peer... then full nodes<br>
could pick and choose which lite nodes they're willing to do (a lot<br>
of) hard work for. This would also be valuable because some modes of<br>
lite operation require non-zero trust of the full node being queried.<br>
</blockquote></div><br>
--0015174c103669976804b44fa66d--
|
