<oembed><type>rich</type><version>1.0</version><author_name>npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2p</author_name><author_url>https://nostr.ae/npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2p</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2014-04-10&#xA;📝 Original message:On Thu, Apr 10, 2014 at 8:04 AM, Tamas Blummer &lt;tamas at bitsofproof.com&gt;wrote:&#xA;&#xA;&gt; Serving headers should be default but storing and serving full blocks&#xA;&gt; configurable to ranges, so people can tailor to their bandwith and space&#xA;&gt; available.&#xA;&gt;&#xA;&#xA;I do agree that it is important.&#xA;&#xA;This does require changes to the P2P protocol, as currently there is no way&#xA;for a node to signal that they store only part of the block chain. Also,&#xA;clients will have to be modified to take this into account. Right now they&#xA;are under the assumption that every full node can send them every&#xA;(previous) block.&#xA;&#xA;What would this involve?&#xA;&#xA;Do you know of any previous work towards this?&#xA;&#xA;Wladimir&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/fb3a77bb/attachment.html&gt;</html></oembed>