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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B84567D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 May 2016 09:47:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAA381FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 20 May 2016 09:47:29 +0000 (UTC)
Received: from neubau-gw.kalkbreite.net ([62.12.170.156]:45468
helo=[172.27.201.177])
by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.86_1) (envelope-from <jl2012@xbt.hk>)
id 1b3h1k-0016FW-GB; Fri, 20 May 2016 05:47:28 -0400
Content-Type: multipart/signed;
boundary="Apple-Mail=_009F9BD2-07A6-4A0F-83E3-55C62937D140";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail 2.6b2
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <20160517132311.GA21656@fedora-21-dvm>
Date: Fri, 20 May 2016 11:46:32 +0200
Message-Id: <68A4772D-D423-45F9-ADB7-95BEB3E66F43@xbt.hk>
References: <20160517132311.GA21656@fedora-21-dvm>
To: Peter Todd <pete@petertodd.org>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With
Low-Latency Delayed TXO Commitments
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, 20 May 2016 09:47:30 -0000
--Apple-Mail=_009F9BD2-07A6-4A0F-83E3-55C62937D140
Content-Type: multipart/alternative;
boundary="Apple-Mail=_8871C9B6-9DFD-42D8-B917-373CE934C7BA"
--Apple-Mail=_8871C9B6-9DFD-42D8-B917-373CE934C7BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
How is this compared to my earlier proposal: =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/0119=
52.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011=
952.html> ?
In my proposal, only the (pruned) UTXO set, and 32 bytes per archived =
block, are required for mining. But it is probably more difficult for =
people to spend an archived output. They need to know the status of =
other archived outputs from the same block. A full re-scan of the =
blockchain may be needed to generate the proof but this could be done by =
a third party archival node.
>=20
>=20
>=20
> ## Implementation
>=20
> Our proposed high-performance/low-latency delayed commitment full-node
> implementation needs to store the following data:
>=20
> 1) UTXO set
>=20
> Low-latency K:V map of txouts definitely known to be unspent. =
Similar to
> existing UTXO implementation, but with the key difference that old,
> unspent, outputs may be pruned from the UTXO set.
>=20
>=20
> 2) STXO set
>=20
> Low-latency set of transaction outputs known to have been spent by
> transactions after the most recent TXO commitment, but created =
prior to the
> TXO commitment.
>=20
>=20
> 3) TXO journal
>=20
> FIFO of outputs that need to be marked as spent in the TXO MMR. =
Appends
> must be low-latency; removals can be high-latency.
>=20
>=20
> 4) TXO MMR list
>=20
> Prunable, ordered list of TXO MMR's, mainly the highest pending =
commitment,
> backed by a reference counted, cryptographically hashed object =
store
> indexed by digest (similar to how git repos work). High-latency ok. =
We'll
> cover this in more in detail later.
>=20
>=20
--Apple-Mail=_8871C9B6-9DFD-42D8-B917-373CE934C7BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">How is this compared to my earlier proposal: <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decem=
ber/011952.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-De=
cember/011952.html</a> ?<div class=3D""><br class=3D""></div><div =
class=3D"">In my proposal, only the (pruned) UTXO set, and 32 bytes per =
archived block, are required for mining. But it is probably more =
difficult for people to spend an archived output. They need to know the =
status of other archived outputs from the same block. A full re-scan of =
the blockchain may be needed to generate the proof but this could be =
done by a third party archival node.</div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D""><br =
class=3D""></div><div class=3D""><div class=3D""><br class=3D""><br =
class=3D"">## Implementation<br class=3D""><br class=3D"">Our proposed =
high-performance/low-latency delayed commitment full-node<br =
class=3D"">implementation needs to store the following data:<br =
class=3D""><br class=3D"">1) UTXO set<br class=3D""><br class=3D""> =
Low-latency K:V map of txouts definitely known to be =
unspent. Similar to<br class=3D""> existing UTXO =
implementation, but with the key difference that old,<br class=3D""> =
unspent, outputs may be pruned from the UTXO set.<br =
class=3D""><br class=3D""><br class=3D"">2) STXO set<br class=3D""><br =
class=3D""> Low-latency set of transaction outputs =
known to have been spent by<br class=3D""> =
transactions after the most recent TXO commitment, but =
created prior to the<br class=3D""> TXO commitment.<br =
class=3D""><br class=3D""><br class=3D"">3) TXO journal<br class=3D""><br =
class=3D""> FIFO of outputs that need to be marked as =
spent in the TXO MMR. Appends<br class=3D""> must be =
low-latency; removals can be high-latency.<br class=3D""><br =
class=3D""><br class=3D"">4) TXO MMR list<br class=3D""><br class=3D""> =
Prunable, ordered list of TXO MMR's, mainly the =
highest pending commitment,<br class=3D""> backed by a =
reference counted, cryptographically hashed object store<br class=3D""> =
indexed by digest (similar to how git repos work). =
High-latency ok. We'll<br class=3D""> cover this in =
more in detail later.<br class=3D""><br class=3D""><br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=
--Apple-Mail=_8871C9B6-9DFD-42D8-B917-373CE934C7BA--
--Apple-Mail=_009F9BD2-07A6-4A0F-83E3-55C62937D140
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQGcBAEBCgAGBQJXPt0tAAoJEO6eVSA0viTSwE4MAK7xbzaLv577x9wdYWZZAHDs
GbAq95HISuQT5x0z+s+mKPqV2Y60YztW6qEo2tzkPKMQdwKYyNRmAPjCYDE5jsfz
0QQFcbB8AKp2W2LT43Lf9++FaqX6BL3SJY14rE4qyCd/hqHIkblzdbziOrRz507G
JRolGcP6mgylizjRn+Bsb/r1uB317xgNyjCX9nzS+VtOCSIn+fxoUpPXpe9/tssY
egeoOTZFBOOJwy4s79BUBTCRuBsqNJvaIc6SMN9ZpGfrzp+F2HQLOEmwj6r1aNQj
FslHzp0otcW7eifyVQo2bBE7RuQ5kyqYwhIz8DfeW95w4Qb+9W4Uwwa4ncTBppqj
x6yVNjaGAYL/Gs2egPbX41uIDsvQ0ZpO08qjLkj6ZSC70TbRZ1SiJTp+hlfyLgWb
WMrTSVuiLY3BFVU4CrQ6+ihyklkjZDBHBRpefEPt1nz/3teO0HzD1shkRQgKdcdu
STSTIi5As7qdB9duPhIF7s5WmzrglAGcOa4XuOqlMA==
=PKSg
-----END PGP SIGNATURE-----
--Apple-Mail=_009F9BD2-07A6-4A0F-83E3-55C62937D140--
|
