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
|
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 513B95AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 23:13:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f49.google.com (mail-it0-f49.google.com
[209.85.214.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9154D169
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 23:13:44 +0000 (UTC)
Received: by mail-it0-f49.google.com with SMTP id h10so3156428ith.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 15:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=XjemXPZNErywBT4I9QI5B94lC1QPGjh95f38wp0L/jI=;
b=i88tSlUMQJcOhB2VccyoU4YtYnqQtyYtDogUZInuabb1ZrBXaRCLP4VMAdE83n0FKo
XpAcshUPHK1a3P321oOQAZp89ToXTucidZBBI8mRGyMCGw31wZhR0PpmztLZSgcUf5hc
dZjTmBHzijrIgTlcrkZlH9brTyjgxekzrCfStaAd7oqlvXXtmkT5c5m8mgjusD/BHfDz
YvOkZ9JaTRyjgAEos3VCkVqYclJY2vtxB6PL18DIt/KgvZ5wQv+6YIsLrZSFZ38v8awe
A39T+5HlJ10mvZZo01QU/2Iikmwv1Prr8bxpYTdRtXcbN/XTshPwBIiWQl53NDF+zKZn
xlxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=XjemXPZNErywBT4I9QI5B94lC1QPGjh95f38wp0L/jI=;
b=G9ln+o24h5Bp88qAwQZPhEt7fRnEIJkufmyp9mo2TdOElxEt4eVrqTUcjNJ8S+sEfQ
JQbvyjx/BJjQT70Z8gJdi84qeRE32Mc+pcKUBN1CfPQcP7g4wK9CWzzkaj68EB4w6Zj5
IGjypINv3fodIvidjjsV7bY+dZABaBlRDAZ6DSq2fHzE2MdRguP43PJ93TIOjy8pr70G
d/jSy2+an3NsDpj9jVQQAr1Wvn7UBTib6GjxP0lc4srXkO3NcBDnki97q/lT6P6lvmDH
3D0hlOxBFuMSwMbQB7AW3f5XV3Ng/snkwf3EARIxCEXL7CEhRaVBhpYwosMxs73aB2jm
uK2A==
X-Gm-Message-State: AMke39kY2k+PAwWQAJDD+EwKsFxsVfm9rVdSeGm2O7ik709bQiqT4gXIA/K64jnzpufCMgOpgUwvisHqzv80T0XK
X-Received: by 10.36.1.147 with SMTP id 141mr68696itk.65.1487891623844; Thu,
23 Feb 2017 15:13:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.73.150 with HTTP; Thu, 23 Feb 2017 15:13:43 -0800 (PST)
In-Reply-To: <CAAcC9ys5sUxVfOjogFiF3gzk51D_L=QQkOYevTH=qbh_RkA3Hw@mail.gmail.com>
References: <20170223011506.GC905@savin.petertodd.org>
<CAAcC9ys5sUxVfOjogFiF3gzk51D_L=QQkOYevTH=qbh_RkA3Hw@mail.gmail.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Thu, 23 Feb 2017 15:13:43 -0800
Message-ID: <CA+KqGkrUneGe4yORi=JAAWzoO0UftMUuJm3S-__W5sBh-+T1vQ@mail.gmail.com>
To: Chris Priest <cp368202@ohiou.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143d464b451ab05493ac3e1
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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] A Better MMR Definition
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: Thu, 23 Feb 2017 23:13:52 -0000
--001a1143d464b451ab05493ac3e1
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What problem does this try to solve, and what does it have to do with
> bitcoin?
>
I can't speak to MMRs (they look a bit redundant with the actual blockchain
history to my eye) but circling back to utxo commitments, the benefits are
that it enables actual proofs of non-fraud: You can prove the validity of a
block based on just the previous block (and maybe some previous headers
because of mining rewards) and can prove to a light node that a utxo hasn't
been spent yet.
A major factor in the way of getting utxo commitments in blocks is
performance. The txo set is of course vastly larger and more unwieldy. If
you make the utxo commitments trail by a small fixed number of blocks
(between 2 and 5) their latency problems shouldn't be a big deal as long as
the overall performance is good enough. My thesis is that with appropriate
format and implementation tricks it's possible to get performance good
enough to no longer be a gating factor to deployment.
Disappointingly there hasn't been any feedback about my implementation,
just discussion about merkle sets generally.
--001a1143d464b451ab05493ac3e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <span dir=3D"ltr"=
><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div><div class=3D"h5"><br>
</div></div>What problem does this try to solve, and what does it have to d=
o with bitcoin?<br></blockquote><div><br></div><div>I can't speak to MM=
Rs (they look a bit redundant with the actual blockchain history to my eye)=
but circling back to utxo commitments, the benefits are that it enables ac=
tual proofs of non-fraud: You can prove the validity of a block based on ju=
st the previous block (and maybe some previous headers because of mining re=
wards) and can prove to a light node that a utxo hasn't been spent yet.=
=C2=A0</div><div><br></div><div>A major factor in the way of getting utxo c=
ommitments in blocks is performance. The txo set is of course vastly larger=
and more unwieldy. If you make the utxo commitments trail by a small fixed=
number of blocks (between 2 and 5) their latency problems shouldn't be=
a big deal as long as the overall performance is good enough. My thesis is=
that with appropriate format and implementation tricks it's possible t=
o get performance good enough to no longer be a gating factor to deployment=
.=C2=A0</div><div><br></div><div>Disappointingly there hasn't been any =
feedback about my implementation, just discussion about merkle sets general=
ly.=C2=A0</div></div></div></div>
--001a1143d464b451ab05493ac3e1--
|
