From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 351F3B61 for ; Tue, 18 Apr 2017 10:50:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1F7217E for ; Tue, 18 Apr 2017 10:50:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 8544E21E1F; Tue, 18 Apr 2017 12:50:33 +0200 (CEST) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org, David Vorick Date: Tue, 18 Apr 2017 12:50:31 +0200 Message-ID: <2226058.Q8lHjYE4Pt@strawberry> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 18 Apr 2017 12:17:20 +0000 Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 10:50:39 -0000 On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote: > The best alternative today to storing the full blockchain is to run a > pruned node The idea looks a little overly complex to me. I suggested something similar which is a much simpler version; https://zander.github.io/scaling/Pruning/ > # Random pruning mode > > There is a large gap between the two current modes of everything > (currently 75GB) and only what we need (2GB or so). > > This mode would have two areas, it would keep a days worth of blocks to > make sure that any reorgs etc would not cause a re-download, but it would > have additionally have an area that can be used to store historical data > to be shared on the network. Maybe 20 or 50GB. > > One main feature of Bitcoin is that we have massive replication. Each node > currently holds all the same data that every other node holds. But this > doesn't have to be the case with pruned nodes. A node itself has no need > for historic data at all. > > The suggestion is that a node stores a random set of blocks. Dropping > random blocks as the node runs out of disk-space. Additionally, we would > introduce a new way to download blocks from other nodes which allows the > node to say it doesn't actually have the block requested. > > The effect of this setup is that many different nodes together end up > having the total amount of blocks, even though each node only has a > fraction of the total amount. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel