Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=ricardojdfilipe@gmail.com;
	helo=mail-la0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+8xBpdY9Vi+K0Cxr_AJ25Y2ieB=0EueiPHq92pdr5QdBnNj_A@mail.gmail.com>
References: <CALC81CNMTWhAQ8VSxToGcSPeJmfFJrANrdXONseTq1=WKm4=7w@mail.gmail.com>
	<CA+8xBpdY9Vi+K0Cxr_AJ25Y2ieB=0EueiPHq92pdr5QdBnNj_A@mail.gmail.com>
Date: Thu, 16 May 2013 17:23:23 +0100
Message-ID: <CALC81CMRKCyvA+q7tQ8GUh_-T1N67_RQru+Vu-UCfaGQG_oVSQ@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Precedence: list

Of course.
My proposal was just for the pruned nodes.
I.e. You would have a majority (maybe not even a majority required) of
nodes storing the whole blockchain and pruned nodes would store
"random" parts of the blockchain, according to the resources they
have, which would be organized as a DHT.

2013/5/16 Jeff Garzik <jgarzik@exmulti.com>:
> On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe
> <ricardojdfilipe@gmail.com> wrote:
>> We would only end up with few copies of the historic data if users
>> could choose what parts of the blockchain to store. Simply store
>> chunks randomly, according to users available space, and give priority
>> to the "N most recent" chunks to have more replicas in the network.
>>
>> You don't need bittorrent specifically for a DHT, if publicity is a
>> problem. There are many DHT proposals and implementations, and i bet
>> one of them should be more suitable to the bitcoin network than
>> bittorrent's.
>
> That's just about the worst thing you could do for bitcoin.  DoS one
> part of the DHT, you DoS the entire blockchain by breaking the chain.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com