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
|
Return-Path: <cory@coryfields.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 53F9F1048
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 17:16:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com
[74.125.82.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA351A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 17:16:58 +0000 (UTC)
Received: by mail-ot0-f172.google.com with SMTP id n1-v6so5903206otf.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 10:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=coryfields-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:reply-to:from:date:message-id
:subject:to:cc;
bh=T3aUL2ij42B7cfQFv47CINhK+e2M0yQQq4tVzaWixL4=;
b=T3NCTYnX1dJxJTWkdbE2oDiWIiR6w+FZHbBn4zAiA+/NGaglPOQjA70d50Ws+5Gz35
rcJrK8qhCTK3WDWtgQ6s6zVzNyB/uaUF/TfDsp1IjOzuD/EtT63PYAGIvsIatnmoIaoB
znZF6NkcsLxC2zhYf9t4pgHCl9qxsqGjh7/ZXTSXH4KmZ72EzXiVKCW7WXWZRDAceZAs
4gDpLmepKuExuQPnYsrxl4v5SHIqDut15NlBiGdK5Y8VZo6GCKrR7wcBBBvS6NtaOQ9U
htxqbHiPd2FIt1geyxFL5nxLno0oXVt//QzEd3gRa46UPMBP/12PNcg41UH3Fi3Oq87Y
Qtuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:reply-to
:from:date:message-id:subject:to:cc;
bh=T3aUL2ij42B7cfQFv47CINhK+e2M0yQQq4tVzaWixL4=;
b=SBae3dPUszoDN4ONHaRSh0WawLXiNsleZsWNJs1ug6qy/mdlrnk3/UXlTC3hHHhd5/
HdIEIRfio9EnYwX+18FzVt41mUQkPhZ9Rj3kKj+c2E0A5x0GEJf6+lu+FP7Q5Mua7ng9
T73xxFOKQKEk2QdU6HszGe3uGB6NEHLnKU+7tzO/KiwZL+wBwkkn4+yscrID8ieOXsBe
MGJA+cDW1+nHdbVDnaRruGem8qkjveBw1O20+xDliLeLgfjhmThUD34Z35NAPnDd8F1l
Azlj5xt5OSQfZvSdHv4rYoBcJkB6l1ncxOzlmqmdJ/HvURzObyQLNG/4cAqAqWjQUTwz
lehw==
X-Gm-Message-State: ALKqPwe+92zOIRNJBR4XwRc9ccgAQZj5aG2YPtHYPmXIbudFfaHnHKKM
+8dCKnPqxHMEX6lVle3O3JOjSAoGKTlh52ZMJ+l+jQ==
X-Google-Smtp-Source: AB8JxZrLWVGozlFvVDKNB/GOlTGI3SCyusBKb7VzfyF0LUJgjJRKj7hVlCAwhsWVbZlhKOMzm2SnoI2Ix8qYZkW+Biw=
X-Received: by 2002:a9d:48c6:: with SMTP id
a6-v6mr4003653otj.359.1526577417832;
Thu, 17 May 2018 10:16:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAApLimjfPKDxmiy_SHjuOKbfm6HumFPjc9EFKvw=3NwZO8JcmQ@mail.gmail.com>
<CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
In-Reply-To: <CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
Reply-To: lists@coryfields.com
From: Cory Fields <lists@coryfields.com>
Date: Thu, 17 May 2018 13:16:46 -0400
Message-ID: <CAApLimg2vwfoDPb=q5X8NcU76UPfLSPBhNv=9ECqamK+cVTxmQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="000000000000b66287056c6a0038"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] UHS: Full-node security without maintaining a
full UTXO set
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, 17 May 2018 17:16:59 -0000
--000000000000b66287056c6a0038
Content-Type: text/plain; charset="UTF-8"
Matt: That's a good point. I'll do up a chart comparing utxo size at each
block, as well as comparing over-the-wire size for each block. I think the
period of coalescing earlier this year should be a good example of what
you're describing.
Greg: heh, I was wondering how long it would take for someone to point out
that I'm cheating. I avoided using the word "compression", mostly to
side-step having the discussion turning into reworking the wire
serialization. But you're absolutely right, the de-duping benefits are
independent of the UHS use-case.
Cory
On Thu, May 17, 2018, 12:56 PM Gregory Maxwell <greg@xiph.org> wrote:
> On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Tl;dr: Rather than storing all unspent outputs, store their hashes.
>
> My initial thoughts are it's not _completely_ obvious to me that a 5%
> ongoing bandwidth increase is actually a win to get something like a
> 40% reduction in the size of a pruned node (and less than a 1%
> reduction in an archive node) primarily because I've not seen size of
> a pruned node cited as a usage limiting factor basically anywhere. I
> would assume it is a win but wouldn't be shocked to see a careful
> analysis that concluded it wasn't.
>
> But perhaps more interestingly, I think the overhead is not really 5%,
> but it's 5% measured in the context of the phenomenally inefficient tx
> mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).
> Napkin math on the size of a txn alone tells me it's more like a 25%
> increase if you just consider size of tx vs size of
> tx+scriptpubkeys,amounts. If I'm not missing something there, I think
> that would get in into a very clear not-win range.
>
> On the positive side is that it doesn't change the blockchain
> datastructure, so it's something implementations could do without
> marrying the network to it forever.
>
--000000000000b66287056c6a0038
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Matt: That's a good point. I'll do up a chart com=
paring utxo size at each block, as well as comparing over-the-wire size for=
each block. I think the period of coalescing earlier this year should be a=
good example of what you're describing.<div dir=3D"auto"><br></div><di=
v dir=3D"auto">Greg: heh, I was wondering how long it would take for someon=
e to point out that I'm cheating. I avoided using the word "compre=
ssion", mostly to side-step having the discussion turning into reworki=
ng the wire serialization. But you're absolutely right, the de-duping b=
enefits are independent of the UHS use-case.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Cory</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">On Thu, May 17, 2018, 12:56 PM Gregory Maxwell <<a href=3D"mai=
lto:greg@xiph.org" target=3D"_blank" rel=3D"noreferrer">greg@xiph.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 16, 2018 at 4=
:36 PM, Cory Fields via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefer=
rer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
> wrote:<br>
> Tl;dr: Rather than storing all unspent outputs, store their hashes.<br=
>
<br>
My initial thoughts are it's not _completely_ obvious to me that a 5%<b=
r>
ongoing bandwidth increase is actually a win to get something like a<br>
40% reduction in the size of a pruned node (and less than a 1%<br>
reduction in an archive node) primarily because I've not seen size of<b=
r>
a pruned node cited as a usage limiting factor basically anywhere. I<br>
would assume it is a win but wouldn't be shocked to see a careful<br>
analysis that concluded it wasn't.<br>
<br>
But perhaps more interestingly, I think the overhead is not really 5%,<br>
but it's 5% measured in the context of the phenomenally inefficient tx<=
br>
mechanisms ( <a href=3D"https://bitcointalk.org/index.php?topic=3D1377345.0=
" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://bitcoi=
ntalk.org/index.php?topic=3D1377345.0</a> ).<br>
Napkin math on the size of a txn alone tells me it's more like a 25%<br=
>
increase if you just consider size of tx vs size of<br>
tx+scriptpubkeys,amounts.=C2=A0 If I'm not missing something there, I t=
hink<br>
that would get in into a very clear not-win range.<br>
<br>
On the positive side is that it doesn't change the blockchain<br>
datastructure, so it's something implementations could do without<br>
marrying the network to it forever.<br>
</blockquote></div>
--000000000000b66287056c6a0038--
|
