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
|
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 E1503B3F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 00:49:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f44.google.com (mail-it0-f44.google.com
[209.85.214.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 466BF16A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Feb 2017 00:49:02 +0000 (UTC)
Received: by mail-it0-f44.google.com with SMTP id 203so5125121ith.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Feb 2017 16:49:02 -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=hWJHSuVlsJOHeAZN5lNTJjWtaxD5YJHosiWY3mEzkuQ=;
b=NyrsMdmVWAau49SJDUMamfGFn7+72eP2yNaw3oLQtLgur2ZbPlS/smE/6Vf83PMTw6
RqWiek3Pwy2dONRmo6UoiAxkfYtIzB83jbFMcoxwGcTLmJVPnbSm4+3v4Tt/UB9o5H3z
8vqsU/2Q8RnFyiw7H9MIU51qoHxj6hcJJJtyY+x4/lKXqEXrbdcUwieZOyuDX6FwSTWd
Hd2Mpm23SVwjTqdrDHPECnnXt8cLL2d5kixLksL6GFDp3ONeuMb1VcWCH1FTVhzOCQTU
Eq+PKuzuL70bjHJlL82mAujCRIrkruBeJqqkbF26Nw7SoJdaSaZIGNNzwCvGJCpnVzN4
eBXw==
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=hWJHSuVlsJOHeAZN5lNTJjWtaxD5YJHosiWY3mEzkuQ=;
b=NuhkRE8Ct3pnv+TAse3dnRCpYw2e+MAe9piuu+ml3EXhuwCmmqerveVPRM9YPy4El5
DnyTrH5S4NanjeKrZq1u4Q2DhuqTyo1yS88MLACVWN8knPupSRSxZ1Xtoxt+VLny5ncV
4z4f/3pn2QAnhW5bnodZRKdcn2tNm+BToH8r9koGzxgchJLDXsrdTN2oQ1gPWFTHoRBG
tL6y4e7hc3kIpUGXHRVreZiJK7olFVYVoJHDWl9d7F6G7gPO3/P5+l2fwxKipEP4KJEo
bGg5z1Y5CHEPYfPJ0YXA1Gdsju3UVg1nR8cjOa9wOS3y1o6wSRDV9EUmeD/LkS4ZH8V4
EYwA==
X-Gm-Message-State: AMke39k5W0xdw7e4o3J3L1f03rgtA7hOsbjBtEQ814d/o0A9d/Shm8cUscfhxYdUZbMoTmd9Z1BJuSlXrEHQVtT6
X-Received: by 10.107.34.10 with SMTP id i10mr457631ioi.41.1487897341557; Thu,
23 Feb 2017 16:49:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.73.150 with HTTP; Thu, 23 Feb 2017 16:49:01 -0800 (PST)
In-Reply-To: <20170223235105.GA28497@savin.petertodd.org>
References: <20170223011506.GC905@savin.petertodd.org>
<CAAcC9ys5sUxVfOjogFiF3gzk51D_L=QQkOYevTH=qbh_RkA3Hw@mail.gmail.com>
<CA+KqGkrUneGe4yORi=JAAWzoO0UftMUuJm3S-__W5sBh-+T1vQ@mail.gmail.com>
<20170223235105.GA28497@savin.petertodd.org>
From: Bram Cohen <bram@bittorrent.com>
Date: Thu, 23 Feb 2017 16:49:01 -0800
Message-ID: <CA+KqGkowxEZeAFYa2JJchBDtRkg1p3YZNocivzu3fAtgRLDRBQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1140ec6881991505493c182f
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Fri, 24 Feb 2017 00:49:03 -0000
--001a1140ec6881991505493c182f
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd <pete@petertodd.org> wrote:
> On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> >
> > 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
>
> In what way do you see MMRs as redundant?
>
You can readily prove something is in the TXO or STXO set using the actual
blockchain, and the proofs will be nice and compact because even light
nodes are expected to already have all the historical headers.
What you can't do with MMRs or the blockchain is make a compact proof that
something is still in the utxo set, which is the whole point of utxo
commitments.
It's totally reasonable for full nodes to independently update and
recalculate the utxo set as part of their validation process. The same
can't be done for a balanced version of the txo set because it's too big.
Relying on proofs as a crutch for using the full txo set would badly
exacerbate the already extant problem of miners doing spv mining, and
increase the bandwidth a full validating node had to use by a multiple.
This whole conversation is badly sidetracked. If people have comments on my
merkle set I'd like to engage further with them, but mmrs need to be argued
independently on their own merits before being used as a counterpoint to
utxo commitments.
--001a1140ec6881991505493c182f
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 3:51 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, Feb 23,=
2017 at 03:13:43PM -0800, Bram Cohen wrote:<br>><br>
> I can't speak to MMRs (they look a bit redundant with the actual b=
lockchain<br>
> history to my eye) but circling back to utxo commitments, the benefits=
are<br>
<br>
</span>In what way do you see MMRs as redundant?<br></blockquote><div><br><=
/div><div>You can readily prove something is in the TXO or STXO set using t=
he actual blockchain, and the proofs will be nice and compact because even =
light nodes are expected to already have all the historical headers.</div><=
div><br></div><div>What you can't do with MMRs or the blockchain is mak=
e a compact proof that something is still in the utxo set, which is the who=
le point of utxo commitments.</div><div><br></div><div>It's totally rea=
sonable for full nodes to independently update and recalculate the utxo set=
as part of their validation process. The same can't be done for a bala=
nced version of the txo set because it's too big. Relying on proofs as =
a crutch for using the full txo set would badly exacerbate the already exta=
nt problem of miners doing spv mining, and increase the bandwidth a full va=
lidating node had to use by a multiple.</div><div><br></div><div>This whole=
conversation is badly sidetracked. If people have comments on my merkle se=
t I'd like to engage further with them, but mmrs need to be argued inde=
pendently on their own merits before being used as a counterpoint to utxo c=
ommitments.</div><div><br></div></div></div></div>
--001a1140ec6881991505493c182f--
|
