From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYIKY-0007A9-KT for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 17:00:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.173 as permitted sender) client-ip=209.85.213.173; envelope-from=pieter.wuille@gmail.com; helo=mail-ig0-f173.google.com; Received: from mail-ig0-f173.google.com ([209.85.213.173]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYIKV-0007Mx-Vi for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 17:00:00 +0000 Received: by mail-ig0-f173.google.com with SMTP id hl10so8048690igb.0 for ; Thu, 10 Apr 2014 09:59:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.120.15 with SMTP id d15mr14541788icr.35.1397149194625; Thu, 10 Apr 2014 09:59:54 -0700 (PDT) Received: by 10.50.141.135 with HTTP; Thu, 10 Apr 2014 09:59:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 18:59:54 +0200 Message-ID: From: Pieter Wuille To: Brian Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WYIKV-0007Mx-Vi Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Chain pruning X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:00:02 -0000 On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman wrote: > Looks like only about ~30% disk space savings so I see your point. Is there > a critical reason why blocks couldn't be formed into "superblocks" that are > chained together and nodes could serve a specific superblock, which could be > pieced together from different nodes to get the full blockchain? This would > allow participants with limited resources to serve full portions of the > blockchain rather than limited pieces of the entire blockchain. As this is a suggestion that I think I've seen come up once a month for the past 3 years, let's try to answer it thoroughly. The actual "state" of the blockchain is the UTXO set (stored in chainstate/ by the reference client). It's the set of all unspent transaction outputs at the currently active point in the block chain. It is all you need for validating future blocks. The problem is, you can't just give someone the UTXO set and expect them to trust it, as there is no way to prove that it was the result of processing the actual blocks. As Bitcoin's full node uses a "zero trust" model, where (apart from one detail: the order of otherwise valid transactions) it never assumes any data received from the outside it valid, it HAS to see the previous blocks in order to establish the validity of the current UTXO set. This is what initial block syncing does. Nothing but the actual blocks can provide this data, and it is why the actual blocks need to be available. It does not require everyone to have all blocks, though - they just need to have seen them during processing. A related, but not identical evolution is merkle UTXO commitments. This means that we shape the UTXO set as a merkle tree, compute its root after every block, and require that the block commits to this root hash (by putting it in the coinbase, for example). This means a full node can copy the chain state from someone else, and check that its hash matches what the block chain commits to. It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some point in the past). In essence, combining both ideas means you get "superblocks" (the UTXO set is essentially the summary of the result of all past blocks), in a way that is less-than-currently-but-perhaps-still-acceptably-validated. -- Pieter