Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.178 as permitted sender)
	client-ip=209.85.223.178; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ie0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CA+s+GJCQSCUyq7Ajv0EgZ8Vbcv4Xt7G-y_8D12fsoKjyFjnhwg@mail.gmail.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
	<CAAt2M18z_Qkqat1OETiXAz0QQey4+y5J6=pC7nkoJfyfrpj3=A@mail.gmail.com>
	<CAAS2fgScWkentFy7Ak0bpYVLsOFL+xkwPm5QRu9ENeX9oCtPug@mail.gmail.com>
	<534570A2.9090502@gmx.de>
	<CA+s+GJAXu3SEXFDDwi85dNFjO2rfPXJrg-aKHYwbogAHfu3vfQ@mail.gmail.com>
	<0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com>
	<CA+s+GJCQSCUyq7Ajv0EgZ8Vbcv4Xt7G-y_8D12fsoKjyFjnhwg@mail.gmail.com>
Date: Thu, 10 Apr 2014 13:32:44 +0200
Message-ID: <CAPg+sBjWL_hKhWW-6i=WAHnx+Ue5JE=A9RrxnWuAYOXw19qiDw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
	wallets
Precedence: list

There were earlier discussions.

The two ideas were either using one or a few service bits to indicate
availability of blocks, or to extend addr messages with some flags to
indicate this information.

I wonder whether we can't have a hybrid: bits to indicate general
degree of availability of blocks (none, only recent, everything), but
indicate actual availability only upon actually connecting (through a
"version" extension, or - preferably - a separate message). Reason is
that the actual blocks available are likely to change frequently (if
you keep the last week of blocks, a 3-day old addr entry will have
quite outdated information), and not that important to actual peer
selection - only to drive the decision which blocks to ask after
connection.

On Thu, Apr 10, 2014 at 1:09 PM, Wladimir <laanwj@gmail.com> wrote:
> On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer <tamas@bitsofproof.com>
> wrote:
>>
>> Serving headers should be default but storing and serving full blocks
>> configurable to ranges, so people can tailor to their bandwith and space
>> available.
>
>
> I do agree that it is important.
>
> This does require changes to the P2P protocol, as currently there is no way
> for a node to signal that they store only part of the block chain. Also,
> clients will have to be modified to take this into account. Right now they
> are under the assumption that every full node can send them every (previous)
> block.
>
> What would this involve?
>
> Do you know of any previous work towards this?
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>