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
|
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 5ECE8BAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Apr 2017 01:29:09 +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 D464A18B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Apr 2017 01:29:08 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id 29CFD20AB4;
Thu, 6 Apr 2017 21:29:08 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Thu, 06 Apr 2017 21:29:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc: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=kkzVXu
1+hgqiyfPg3hJWOH8Mub5+cNvm3eFC6cTp6sQ=; b=EivLNfuheqlojORFxaiyPh
ig3xlLmt2AKpeiBy+5IIY2aikUG2YePuz76IhZ1YvQT7dFMA9CzIQ8oAUJmHnbBc
XyigR/yAA2kjSaJzrbPmDSifbQsSf+W7RkpQkTl26RlAMJQ1oyL5IorwVl70v6sZ
bCOV56UDpsgGXY+sI5q4OHq20MBAcUil9lDhWP0K+GYxnkRStM94PWBgJbx1ugvt
hwqc0SPP4C/cceTWMYZtHJoWzzJHbsXpLmweWh9Y+ssGXncr1JOIUg4W6lT7q9zh
w33wMqxXkRAsSpB0y/5rHlOskh21J+/4Xc6w0IYCc9A6wi8juW0m+0KVb3BB7alg
==
X-ME-Sender: <xms:ZOvmWIYHw95d1Sf9QWsUKn0uiVutrqBnRKKUrHFNhzIvTMRkAqZKhw>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id 0740F9EC32; Thu, 6 Apr 2017 21:29:07 -0400 (EDT)
Message-Id: <1491528547.734012.936970328.62366FA5@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: Gregory Maxwell <greg@xiph.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-8e6aa83c
Date: Fri, 07 Apr 2017 03:29:07 +0200
In-Reply-To: <CAAS2fgR0t=QG6HfhF1MKW3k_4mjv7rjWE4T3-wdiL2fB6TVV4Q@mail.gmail.com>
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>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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: Fri, 07 Apr 2017 01:30:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 07 Apr 2017 01:29:09 -0000
On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote:
>
> How do you deal with validity rules changing based on block height?
I expected that one :). Just like the 100 blocks coinbase rule, changes
by softforks need to be added as metadata to the transaction-index, but
this is not yet in place.
As for the script validation itself using libbitcoinconsensus, this is a
bit hairy as this expects the rules to be known. Luckily, simply
gradually retrying using "lower" rules won't hurt performance, as
transaction that mismatch newer rules are rare.
Generally, bitcrust would appreciate a "is valid with X rules" instead
of a "validate with X rules" approach.
> So it sounds like to work the software still needs an analog of a
> (U)TXO database? I am confused by the earlier comments about thinking
> the the resource consumption of the (U)TXO database is not a
> consideration in your design.
No, but transactional access is. Bitcrust just uses a
*transaction-index*, where outputs can be looked up regardless of being
spent. As the concept of being "spent" depends on the branch, script
validation ignores this and simply looks up the outputs.
Transactions are split in two parts for better locality of reference
when accessing outputs.
The transaction index only looks similar to an "UTXO-index" after full
pruning.
> If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an
> output that never existed how does your spent index reject this spend
The spend-tree is scanned until either DEADBEAF is found (=ERR double
spent), the transaction of DEADBEEF is found (=all ok!), or the start
of the chain is reached (=ERR spending unknown output!)
To prevent actually having to scan to genesis, the spent-index "catches"
the search after a few blocks and performs the same lookup (positive for
tx, negative for output) on a simple bit index.
|
