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.