Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ShpST-0001y6-OK for bitcoin-development@lists.sourceforge.net; Thu, 21 Jun 2012 22:02:33 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com; helo=mail-qc0-f175.google.com; Received: from mail-qc0-f175.google.com ([209.85.216.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1ShpST-0000Lb-2E for bitcoin-development@lists.sourceforge.net; Thu, 21 Jun 2012 22:02:33 +0000 Received: by qcso7 with SMTP id o7so643171qcs.34 for ; Thu, 21 Jun 2012 15:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.74 with SMTP id m10mr9111439qct.41.1340316147605; Thu, 21 Jun 2012 15:02:27 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Thu, 21 Jun 2012 15:02:27 -0700 (PDT) In-Reply-To: References: <4FE0B7EB.6000100@gmail.com> <4FE0C538.3090001@gmail.com> Date: Thu, 21 Jun 2012 18:02:27 -0400 Message-ID: From: Gregory Maxwell To: Mike Koss Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (gmaxwell[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 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1ShpST-0000Lb-2E Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node 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, 21 Jun 2012 22:02:33 -0000 On Thu, Jun 21, 2012 at 5:42 PM, Mike Koss wrote: > Are we just talking about pruning the spent transactions from an old block? No. We're talking about commitments to the state of _unspent_ transactions which would allow ~memoryless nodes to engage in full validation without having to trust anything with the help of some untrusted non-memoryless peers. Also, talking about being able to securely initialize new pruned nodes (not memoryless but reduced memory) without exposing them to the old history of the chain. In both cases this is possible without substantially degrading the full node security model (rule violations prior to where they begin are only undetectable with a conspiracy of the entire network). But it requires a new data structure for managing these trees of unspent transactions in a secure, scalable, and DOS resistant manner. Fortunately there are lots of possibilities here. > Does it really make sense to adopt a more complex data-structure than the merkle tree for inclusing in the bticoin protocol? Yes. Though this is obviously not an ultra short term thing.