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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jordanmack1981@gmail.com>) id 1Rc4sS-0006le-LE
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 00:45:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.175 as permitted sender)
client-ip=209.85.210.175; envelope-from=jordanmack1981@gmail.com;
helo=mail-iy0-f175.google.com;
Received: from mail-iy0-f175.google.com ([209.85.210.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rc4sR-00042X-V9
for bitcoin-development@lists.sourceforge.net;
Sun, 18 Dec 2011 00:45:20 +0000
Received: by iakh37 with SMTP id h37so3810562iak.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 17 Dec 2011 16:45:14 -0800 (PST)
Received: by 10.50.40.135 with SMTP id x7mr18887048igk.24.1324169114583;
Sat, 17 Dec 2011 16:45:14 -0800 (PST)
Received: from [192.168.0.50] (c-67-188-239-72.hsd1.ca.comcast.net.
[67.188.239.72])
by mx.google.com with ESMTPS id x18sm50129099ibi.2.2011.12.17.16.45.12
(version=SSLv3 cipher=OTHER); Sat, 17 Dec 2011 16:45:13 -0800 (PST)
Sender: Jordan Mack <jordanmack1981@gmail.com>
Message-ID: <4EED378A.8090303@parhelic.com>
Date: Sat, 17 Dec 2011 16:44:58 -0800
From: Jordan Mack <jordanmack@parhelic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABr1YTebhitO4g-SarZ7H=aoG9a8zW1wd0rfR32o8i0vODbLJw@mail.gmail.com><82659F61-0449-47BB-88DC-497E0D02F8A1@ceptacle.com><CALxbBHUXEJLRDZ=RS1vuvkm7rDjFUPir0sU__f6TJXiTTQxWzA@mail.gmail.com><CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
<CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.com>
<1324158558.26106.140661012932641@webmail.messagingengine.com>
In-Reply-To: <1324158558.26106.140661012932641@webmail.messagingengine.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
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
(jordanmack1981[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (jordanmack1981[at]gmail.com)
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: 1Rc4sR-00042X-V9
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: Sun, 18 Dec 2011 00:45:20 -0000
While using DHT for storage of the block chain is an intriguing concept,
I do not see how it is feasible. As Gavin noted, DHT is a system that is
difficult to impossible to guarantee against data loss or manipulation.
Even if we found a way to store the block chain in DHT, how would
transactions be verified? As Gavin noted, you could ask the network, but
cannot necessarily trust the peers you are connected to. Verification of
the full block chain allows the client to trust no one.
I also do not see how DHT would solve the problem of scalability in
regards to broadcast messages, although I am definitely interested in
the concept.
|