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 B535DB2A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Apr 2017 10:04:03 +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 CAB6E13C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Apr 2017 10:04:02 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id 2309E20C27;
Tue, 11 Apr 2017 06:04:02 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Tue, 11 Apr 2017 06:04:02 -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=8vvo28
YsbbHy2wIhFHSTMMGcuxi+hkgnvjgwWka2R2s=; b=kecWuI/9tfqLRszmSD/Rq6
rhU2qGW9rz4utociwI0S5DVyC1sJ6A9JoB6AgTv2xdeHPjskRQVkUux/Ec+tIxSz
FAvEzjIYicFl0z0Rgn9c1fbUA4i4ulUHR6sArztXGV+ZJZGRAVBMEUBcKXCNFK4P
u+ovdfmQdeHHiM/XYWzAE+IXSN2nVto0o/E0uLM0+nvFdGbbJ4kxAF3kRxRxJWDC
nLdthN/TBY59tc2LN0G3wqQ9tzxXPx4hmN9drwlwauY3pAXXfD2AWsbs2hkC9Jbm
bdvjCEDxzAZYjnZTnj9rDBiLG0Au19QEH1Kd+plWlCj9zlVWRmjKN5RBTBFpOViw
==
X-ME-Sender: <xms:EqrsWPTV3PhrcxvZpZ9YCPajwESmllvJp1f5Rm9jrmLgZJI6MAL9-Q>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id 035159E124; Tue, 11 Apr 2017 06:04:01 -0400 (EDT)
Message-Id: <1491905041.2824926.941053248.0A8F8971@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Libbitcoin Development <libbitcoin@lists.dyne.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-0b509d77
References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com>
<eebc06a4-5ab8-46a8-2f50-a472cb57a775@voskuil.org>
<1491524267.715789.936916864.1156D8CB@webmail.messagingengine.com>
<83618cca-c6a3-301c-af70-ab7807474f30@voskuil.org>
<1491695882.3440363.938700256.78C37AC3@webmail.messagingengine.com>
<1b6b300d-4b24-2a64-12a3-4e654174c132@voskuil.org>
<1491900210.2802950.940953480.4C391C68@webmail.messagingengine.com>
<83947375-e06b-71dd-1f79-6ca97bea392e@voskuil.org>
In-Reply-To: <83947375-e06b-71dd-1f79-6ca97bea392e@voskuil.org>
Date: Tue, 11 Apr 2017 12:04:01 +0200
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: Tue, 11 Apr 2017 12:50:19 +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: Tue, 11 Apr 2017 10:04:03 -0000
On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:
> It's not the headers/tx-hashes of the blocks that I'm referring to, it
> is the confirmation and spend information relative to all txs and all
> outputs for each branch. This reverse navigation (i.e. utxo
> information) is essential, must be persistent and is branch-relative.
That is exactly what is stored in the spend-tree.
>> As a simpler example, if two miners both mine a block at
>> approximately the same time and send it to each other, then surely
>> they would want to continue mining on their own block. Otherwise
>> they would be throwing away their own reward.
> That's not your concurrent validation scenario. In the scenario you
> described, the person chooses the weaker block of two that require
> validation because it's better somehow, not because it's his own
> (which does not require validation).
> Consistency is reached, despite seeing things at different times,
> because people use the same rules. If the economy ran on arbitrary
> block preference consistency would be elusive.
No but my example shows that it is up to the miner to choose which tip
to work on. This is not using different rules, it is just optimizing its
income. This means that the economy *does* run on arbitrary "block
preference", even if it is not running on arbitrary rules.
If two blocks are competing, a miner could optimize its decision which
to mine on, not just on whether one of the blocks is his own, but also
on fees, or on excessive validation costs.
> I read this as encoding the height at which a fork historically
> activated. If you intend to track activation for each branch that will
> not be "height-based" it will be history based.
I understand "height-based" was not the right wording, as it is of
course branch-specific. Per tip ruleset metadata, must be matched with
per-transaction ruleset metadata.
Tomas
|
