+Return-Path: <tomas@tomasvdw.nl>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E6D7941

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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: <xms:vDjpWFBUk1s9mJAqvMgyska9pAV6NMGjwvWx7unQtCv_7dm6RMf2zQ>

+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 <tomas@tomasvdw.nl>

+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>

+ <CAAS2fgTEMCkDWdhCWt1EsUrnt3+Z_8m+Y1PTsff5Rc0CBnCKWQ@mail.gmail.com>

+ <1491526132.723002.936945760.06A943C6@webmail.messagingengine.com>

+ <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.com>

+ <1491528547.734012.936970328.62366FA5@webmail.messagingengine.com>

+ <CALJP9GAUKt_zXsFkHLhZyVNYr1REUkLM2VvA+vCgqAs6sEEUzA@mail.gmail.com>

+ <CAAS2fgRt33h0j_uwVOfU2mssW_dNCtnS9vckNK8XpQxDgd=Frg@mail.gmail.com>

+ <CALJP9GBn7cCTmzvDeG8DdKPO0YVTgyk9jB9Nn2PY_G=hbTYWvg@mail.gmail.com>

+Date: Sat, 08 Apr 2017 21:23:40 +0200

+In-Reply-To: <CALJP9GBn7cCTmzvDeG8DdKPO0YVTgyk9jB9Nn2PY_G=hbTYWvg@mail.gmail.com>

+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 <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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" <greg@xiph.org> wrote:

+

+>> On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev

+

+>> <bitcoin-dev@lists.linuxfoundation.org> 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"

+

+<!DOCTYPE html>

+<html>

+<head>

+<title></title>

+</head>

+<body><div><br></div>

+<div>On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote:<br></div>

+<blockquote type="cite"><div><div><div><br></div>

+<div><div><br></div>

+<div defang_data-gmailquote="yes"><div>On Apr 7, 2017 12:42, "Gregory Maxwell" &lt;<a href="mailto:greg@xiph.org">greg@xiph.org</a>&gt; wrote:<br></div>

+<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><div>On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev<br></div>

+<div> &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br></div>

+<div> &gt; A network in which many nodes maintain a transaction index also enables a<br></div>

+<div> &gt; class of light node applications that ask peers to prove existence and<br></div>

+<div> &gt; spentness of TXO's.<br></div>

+<div> <br></div>

+</div>

+<div>Only with the additional commitment structure such as those proposed<br></div>

+<div> by Peter Todd in his stxo/txo commitment designs, e.g.<br></div>

+<div> <a href="https://petertodd.org/2016/delayed-txo-commitments">https://petertodd.org/2016/<wbr>delayed-txo-commitments</a><br></div>

+</blockquote></div>

+</div>

+</div>

+<div>Light nodes are improved by detecting invalid transactions, even before they are mined.<br></div>

+</div>

+<div><u>_______________________________________________</u><br></div>

+</blockquote><div><br></div>

+<div>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.&nbsp;<br></div>

+<div><br></div>

+<div>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. <br></div>

+<div><br></div>

+</body>

+</html>

+

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

+

+