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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BA23AB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Apr 2017 09:40:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com
[209.85.192.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16FF815E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Apr 2017 09:40:58 +0000 (UTC)
Received: by mail-pf0-f175.google.com with SMTP id s16so46390593pfs.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Apr 2017 02:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-transfer-encoding;
bh=us48/ORO90xPCxoBR7qlNNlaAIagQdkm19eR35/vM3Y=;
b=EbC5UaaXo3noxk65fuiNedyZD+T4YkpsZ5vHfqUT5noxeGr48GdeBp0/c9HyLoWZCX
csl1q0nAi/57tM44gAf9F5DtVNKSVkN4dpbWHeLTDi5LoMytvSeZgjKfOzTIfG0cJOfi
RaAMMyUr7QNnO9z0b5SVgit14woLMUX+kNNbJA7677JHYvR71aHC5/DL9R95aKcXBxHk
DJOrJOGRXIgYa1Y5gKV1QdKuoUOJxtANkaAuAqTE2/SurU+T1aUSAY17Z8O6EmHjE3YH
0NsGuvTi9IhIVtsvahOcPeFeJUhK1v67GabfOdxazyjqJsP25sCo8XVC5IqQfDxghazw
sr4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding;
bh=us48/ORO90xPCxoBR7qlNNlaAIagQdkm19eR35/vM3Y=;
b=WeNn3NhFyPIHyKC0obzDjC17R4rVZGfBqaTxnA1K6EDcxabgnr28gwHHelt8tccrYy
ukc2vrqwQaLjv5kpyRd+IUdEZnCHYujerOWuvwPZoAls//pez57/KM6zB1S80RB3GKva
M2D8VR6S3ckoQwzcKlivl2f/JOG4GNP9Mdl1GtSz9I9mmzF374g2UihC8RhALCJ9xGm0
18EvunV4HDb+eRZ57Ob5a8RCVS8Tg4S8GHxgDceCmnx6NAhhjVtTRt76W9tHrebq4w8x
I42hhdy4WGPJU/pMTNwwaRyOlo+bqwVhB3Zavw6Mu3difHMRgHReT2S7FgjuXo73nYgJ
uYTg==
X-Gm-Message-State: AFeK/H3juVTgUYVB5vdn7/vNe5C2iYU76XmOeEq90/xGrQP5qOBoVK7ZctvHqrZjiRQTOA==
X-Received: by 10.84.208.102 with SMTP id f35mr75680346plh.19.1491903657578;
Tue, 11 Apr 2017 02:40:57 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:f5d8:bba:67b2:7d87?
([2601:600:9000:d69e:f5d8:bba:67b2:7d87])
by smtp.gmail.com with ESMTPSA id
b70sm29451788pfc.100.2017.04.11.02.40.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 11 Apr 2017 02:40:56 -0700 (PDT)
To: Tomas <tomas@tomasvdw.nl>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Libbitcoin Development <libbitcoin@lists.dyne.org>
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>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <83947375-e06b-71dd-1f79-6ca97bea392e@voskuil.org>
Date: Tue, 11 Apr 2017 02:41:34 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <1491900210.2802950.940953480.4C391C68@webmail.messagingengine.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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 09:40:58 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/11/2017 01:43 AM, Tomas wrote:
> Splitting transactions only happens *on storage* and is just a
> minor optimization compared to storing them in full.
Ok
> Sure, we can still call switching tips a "reorg". And it is indeed
> a trade off as orphan blocks are stored, but a block in the spend
> tree takes only ~12kb and contains the required state information.
>
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.
> The blockchain is - by design - only eventually consistent across
> nodes. Even if nodes would use the same "tip-selection" rules, you
> cannot rely on all blocks being propagated and hence each
> transaction having the same number of confirmations across all
> nodes.
>
> 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).
> And yes, this can also happen over multiple blocks, but the chances
> of consistency are vastly increased with each confirmation.
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.
> I am not talking about rejecting blocks, I am only talking choosing
> on which tip to mine.
This line of reasoning has me a bit baffled. Yet as I said, it's not
important to the question at hand. It is not likely to be optimal to
validate concurrently even if you consider selection of a weaker block
advantageous.
>> If you intend this to be useful it has to help build the chain,
>> not just rely on hardwiring checkpoints once rule changes are
>> presumed to be buried deeply enough to do so (as the result of
>> other implementations ).
>>
>> I understand this approach, it was ours at one time. There is a
>> significant difference, and your design is to some degree based
>> on a failure to fully consider this. I encourage you to not
>> assume any consensus-related detail is too small.
>
> I am not failing to consider this, and I don't consider this too
> small . But ensuring contextual transaction validity by "validate
> => valid with rules X,Y,Z" and then checking the active rules
> (softfork activation) on order validation, will give logically the
> same results as "validate with X,Y,Z => valid". This is not
> "hardwiring checkpoints" at all.
Storing the validation flags with each tx is exactly what libbitcoin
does (otherwise pre-validation would be infeasible). But that was not
the full point. You said on this in response previously:
>>> ...height-based compliance as meta data of validation seems to
>>> be
adequate and safe.
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.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY7KTHAAoJEDzYwH8LXOFOI+QH/RzX++1TNLC9DEMWioE7SmMj
yKOrP8WEkOnnrZdFKxVmwV9oZBekEvDABMnJmFiW5TMjsmPz7XwKAYzV0Y5L5oGU
fZYo3IOPyr0dA9TcpP15gNziR6pFUBq/QTYB6BcbUvvlkJv6xjgIdedgDMEyREWU
Hm/JU5g7gQUQd6MIDWbQ9FbYjtPuNSRQi851YfIn5mDivT4HuidaqQYMd9t5yS2Z
FuoQBI6L5GTJIqml1bTwJ0wsA7+ZseBEgMn1TT1ehy2v1FFJTojTpzIwG+m3eiXg
TxN3U/+fNAj+sKBb8Hq+nb7DvgjvKHyHuyRryBju7yq5d5rsb6meXcoiOtAznP8=
=fRXf
-----END PGP SIGNATURE-----
|
