1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
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" <<a href="mailto:greg@xiph.org">greg@xiph.org</a>> 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> <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br></div>
<div> > A network in which many nodes maintain a transaction index also enables a<br></div>
<div> > class of light node applications that ask peers to prove existence and<br></div>
<div> > 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. <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--
|
