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 5E6D7941 for ; Sat, 8 Apr 2017 19:23:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1EA8130 for ; Sat, 8 Apr 2017 19:23:41 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E955120819 for ; Sat, 8 Apr 2017 15:23:40 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Sat, 08 Apr 2017 15:23:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=T4HddQ L3pZA9DnzqufHPG3kYUKME/lmrg6GRPHX2ifc=; b=AYGr0dgl6vKIrMtqM43gRW yedh7OUq6EPRp4lV9pdTG4x4nMvBedFuP94QX6j1OVOci6q7K6KNsDsH4g9miOB5 PkWLBgaeMWlMbIGE9iDmM/nPv7s2pagnm9JIkPK4SY1kKq7Rrcj7NoGja+exouvh 3uprOh51So9s/0RyHbvDCWnYBAbC1aB3qnIff5amHS6wAEGm9zZbuFSudIS75Gtq +mF3vuvqBtx+z5YTWJt7Db4lqOXYqdY33nuodJtRMEPEPTmKNHlTbP0/3TbiDZmI nTEr9j7qnhThI9lZsVdn7dKTlJRD8ITe+PQy4cyPFdWqQ/BVDe7qgvE3nU86VuUA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C91329EC4C; Sat, 8 Apr 2017 15:23:40 -0400 (EDT) Message-Id: <1491679420.2446184.938577504.77C413F5@webmail.messagingengine.com> From: Tomas To: bitcoin-dev@lists.linuxfoundation.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_149167942024461840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7c174d5d References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com> <1491528547.734012.936970328.62366FA5@webmail.messagingengine.com> Date: Sat, 08 Apr 2017 21:23:40 +0200 In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 08 Apr 2017 19:31:41 +0000 Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index 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: Sat, 08 Apr 2017 19:23:45 -0000 This is a multi-part message in MIME format. --_----------=_149167942024461840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote: > > > On Apr 7, 2017 12:42, "Gregory Maxwell" wrote: >> On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev >> wrote: >> > A network in which many nodes maintain a transaction index also >> > enables a >> > class of light node applications that ask peers to prove >> > existence and >> > spentness of TXO's. >> >> Only with the additional commitment structure such as those proposed >> by Peter Todd in his stxo/txo commitment designs, e.g. >> https://petertodd.org/2016/delayed-txo-commitments > Light nodes are improved by detecting invalid transactions, even > before they are mined. > _________________________________________________ I am not quite sure why you think this approach would help in this regard. I may be missing part of how Core works here, but Bitcrust's txindex is merely used to lookup transactions from hashes and currently, and seems to fulfil the same role as Core's -txindex mode. This can be pruned, and in the future auto-pruned as the "flat files" used as base for all data allow for concurrent pruning. But unlike Core, it is always needed as without UTXO index, it is needed to find outputs during base load validation. --_----------=_149167942024461840 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote:


On Apr 7, 2017 12:42, "Gregory Maxwell" <greg@xiph.org> wrote:
On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.

Only with the additional commitment structure such as those proposed
by Peter Todd in his stxo/txo commitment designs, e.g.
Light nodes are improved by detecting invalid transactions, even before they are mined.
_______________________________________________

I am not quite sure why you think this approach would help in this regard. I may be missing part of how Core works here, but Bitcrust's txindex is merely used to lookup transactions from hashes and currently, and seems to fulfil the same role as Core's -txindex mode. 

This can be pruned, and in the future auto-pruned as the "flat files" used as base for all data allow for concurrent pruning. But unlike Core, it is always needed as without UTXO index, it is needed to find outputs during base load validation.

--_----------=_149167942024461840--