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
|
Return-Path: <majorkusanagibtc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 29806258
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Jul 2017 06:45:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 61A5212A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Jul 2017 06:45:56 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id v139so487630wmv.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Jul 2017 23:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=ep60fBbjsZPohLSyq7o96nqFqIbFtYz9SvSPcVwSV+k=;
b=LKk+R0wICpZ+1L83q0pUCDtPTEUhO15tacr4hqlWm7Kyy4D/fGEWeF66tdDRlR3FZo
6NUOX+Kz4HftB3tftPTEXQMWPbjnua8cDlIHf3hVy6sUwG4J0VD1riWdg9M9I8dACB/W
r92p8giBXW3t/9XVL53DLSTIJRqorBqbv1dM5V868/DYGv0+mfSov0LqBFmgAAeUyjLx
UU32lSw/i83DyATyLpkU0nr79XtXsO2Uf3zeyIYgp1Vu2FWrme5c4abeZptsSvOUU5Wm
tXDa4WAA3x0YPb0ngfFBjRAY4OgAAzmNJscfIIWbLEIp2lNopr0+P+cpUGgJ7akATtLK
9GRw==
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;
bh=ep60fBbjsZPohLSyq7o96nqFqIbFtYz9SvSPcVwSV+k=;
b=bnbdHUH5ryAxCUDTZhC63DeXG4pxH1W5RHZGCyvSvkUW11UqGPg4li/CC7S8uIGLIC
Axb+znUZyvYiZyHxxkgJODWb6gRhoSzhoo6oFfLaYu3o1jAGrcYAUU2g/v+80w6zso0H
hQEbqtSca6z0jjz/M82PX7YGpQIFPJOs+vxR3mxv+H21/wYMNu4tbzsW6/vBz6dw8Uqw
Bx7Dvr9hJKZNtOq9BrSHW6oqaQBcvLu0FrbghqUNdr4U6W0Z6wEQwklY2Fo2CcPp7xw8
gLQgqUDjj1apCQNDkis0Q3cMbq7dIMSOp1YYW93uc6DkF2WSsCfuVcVJNs2iHjHqZ6GR
dLbw==
X-Gm-Message-State: AIVw111TaWHEQJ56C58wLuKGI9CO2WouuAEvDLWjGvVn1+TO8GJAZuS9
AohQMdoHLWJeb4WJNx+wIhLPIH6eHw==
X-Received: by 10.80.175.36 with SMTP id g33mr7897351edd.183.1500705955113;
Fri, 21 Jul 2017 23:45:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.136.55 with HTTP; Fri, 21 Jul 2017 23:45:54 -0700 (PDT)
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
From: Major Kusanagi <majorkusanagibtc@gmail.com>
Date: Fri, 21 Jul 2017 23:45:54 -0700
Message-ID: <CAAU88OrgczrCGZpeP5Q+_LQoFcbkV_-foops7fWmJXQ1VhCZ6w@mail.gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>,
bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="94eb2c0e489a5def2e0554e2553e"
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,
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: Sat, 22 Jul 2017 14:52:30 +0000
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
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: Sat, 22 Jul 2017 06:45:57 -0000
--94eb2c0e489a5def2e0554e2553e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <lvella@gmail.com>
wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> [...] But the fact is that if we want to make bitcoins last forever, we
>> have the accept unbounded UTXO growth, which is unscalable. So the only
>> solution is to limit UTXO growth, meaning bitcoins cannot last forever.
>> This proposed solution however does not prevent Bitcoin from lasting
>> forever.
>>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
> - "Bitcoins lasting forever" implies "unscalable";
> - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
> - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>
I made a distinction between lowercase bitcoin meaning the unit of account
in uppercase Bitcoin, the system as a whole. The proposal would make
bitcoins not last forever, which allows the Bitcoin system to scale better
and have a better chance of lasting forever.
> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount of
> Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have th=
e
> opinion it isn't worth the hassle.
>
Exactly. That=E2=80=99s the whole idea. Why bother have nodes store UTXO=E2=
=80=99s for lost
bitcoins? This proposal would essentially sanitize the UTXO set that nodes
keep track of and clear up wasted space.
As a side note, your estimate talks about block size, which is determines
> blockchain size, which can be "safely" pruned (if you are not considering
> new nodes might want to join the network, in case the full history is
> needed to be stored somewhere). But UTXO size, albeit related to the full
> blockchain size, is the part that currently can not be safely pruned, so =
I
> don't see the relevance of the analysis.
>
> I believe I=E2=80=99ve address this with the checkpoint mechanism in my r=
eply to
Jameson.
> --
> Lucas Clemente Vella
> lvella@gmail.com
>
--94eb2c0e489a5def2e0554e2553e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <span dir=3D"ltr=
"><<a href=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.co=
m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">20=
17-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div><div><div><div>[...] But the f=
act is that if we want to make bitcoins last forever, we have the accept un=
bounded UTXO growth, which is unscalable. So the only solution is to limit =
UTXO growth, meaning bitcoins cannot last forever. This proposed solution h=
owever does not prevent Bitcoin from lasting forever.<br></div></div></div>=
</div></blockquote><div>=C2=A0</div></div>Unless there is a logical contrad=
iction in this phrasing, the proposed solution does not improves scalabilit=
y:<br>=C2=A0- "Bitcoins lasting forever" implies "unscalable=
";<br>=C2=A0- "not prevent Bitcoin from lasting forever" imp=
lies "Bitcoins lasting forever";<br></div><div class=3D"gmail_ext=
ra">=C2=A0- Thus: "not prevent Bitcoin from lasting forever" impl=
ies "unscalable".</div></div></blockquote><div><br></div><div>I m=
ade a distinction between lowercase bitcoin meaning the unit of account in =
uppercase Bitcoin, the system as a whole. The proposal would make bitcoins =
not last forever, which allows the Bitcoin system to scale better and have =
a better chance of lasting forever.<br></div><div><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra">In practice, the only Bitcoin lost would be those whos=
e owners forgot about or has lost the keys, because everyone with a signifi=
cant amount of Bitcoins would always shift them around before it loses any =
luster (I wouldn't bother to move my Bitcoins every 10 years). I don=
9;t know how to estimate the percentage of UTXO is actually lost/forgotten,=
but I have the opinion it isn't worth the hassle.</div></div></blockqu=
ote><div><br></div><div>Exactly. That=E2=80=99s the whole idea. Why bother =
have nodes store UTXO=E2=80=99s for lost bitcoins? This proposal would esse=
ntially sanitize the UTXO set that nodes keep track of and clear up wasted =
space.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">As a side no=
te, your estimate talks about block size, which is determines blockchain si=
ze, which can be "safely" pruned (if you are not considering new =
nodes might want to join the network, in case the full history is needed to=
be stored somewhere). But UTXO size, albeit related to the full blockchain=
size, is the part that currently can not be safely pruned, so I don't =
see the relevance of the analysis.<span class=3D"gmail-HOEnZb"><font color=
=3D"#888888"><br></font></span></div><span class=3D"gmail-HOEnZb"><font col=
or=3D"#888888"><div class=3D"gmail_extra"><br></div></font></span></div></b=
lockquote><div><div>I believe I=E2=80=99ve address this with the checkpoint=
mechanism in my reply to Jameson.</div></div><div><br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span=
class=3D"gmail-HOEnZb"><font color=3D"#888888"><div class=3D"gmail_extra">=
-- <br><div class=3D"gmail-m_-4943972615360180282gmail_signature">Lucas Cle=
mente Vella<br><a href=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella=
@gmail.com</a></div>
</div></font></span></div>
</blockquote></div><br></div></div>
--94eb2c0e489a5def2e0554e2553e--
|
