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
|
Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F85D95D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Jul 2017 20:17:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
[209.85.220.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 167283D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Jul 2017 20:17:41 +0000 (UTC)
Received: by mail-qk0-f175.google.com with SMTP id y126so31651069qke.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Jul 2017 13:17:40 -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
:cc; bh=R2nXeC8rN/NH1BePKYQRxNYQwyVtgLFX2bm6fUP+QpM=;
b=uqazVdtomhWGnr2GpaOGLJjqaLXcth+SrEKuy1mVnvsfCQNasmh0uWH3hT2i1RLwHN
48y985RuNv+s9ufYV+B7buLdmCxnS+E75vdOO0DN7tdK31PkKP0uIdb8sIepa8yHuFE5
icm8fdcxxBVjTxRmYbDMOxhEbCoLGs/GaSw6GaGfW93fuu4QaNiF7RQV/wMnfRHrxjjO
41M2eUUIgk7iMNu4qbcAf9FapqfHJVow+CZRBtqwFFUrN+F1k0U91E8e5zPa2Y+RWQ5C
2yyg/pnLE7dI8ILcRDSVxJ+F1Gn4UOtlToOImgkP9t0K7qJ9lAjf9I89X6Zqz4hM65qt
NAAw==
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=R2nXeC8rN/NH1BePKYQRxNYQwyVtgLFX2bm6fUP+QpM=;
b=ZCp71kp2FE4tk4L72hu1bnzxF5qoiFiVHDOqwfJMBQdSpF9Rvx9ehLVviuwUJla1pJ
7XgL66cdeRB5DV0Iw6adS7OYfJvcVf6xF9WsWxXPgrxOFMEjv2W7kQeHo5sHNelBlPyy
EWE3fSPJMpTAUnhlgTrW1zixDhkQ/vY1j5TKjt5XAas4OgGioZKib2N/s1HhwB/Y/05Y
ElFoiuWj9TLQWP4u2aUDCB0PfOKZ4u2JgyJLedCYo/2IADHEOl+NESp/qlKX6FqQT8Ur
TSFw+v/gJCqFtWPE+5kqa5i/voI/S46+yXGkPD5ehEYhoymtgHgxXZ5EPUFD7qZ0lr3A
CzKA==
X-Gm-Message-State: AIVw110NbU6mq1viDupsV8TbzbgDCgx+wjhNHt+OWf7cwZgFOIoImdHX
ipEQd/f+/n0aEjnf38jKJa020I5M3w==
X-Received: by 10.55.135.196 with SMTP id j187mr10233937qkd.221.1500668260261;
Fri, 21 Jul 2017 13:17:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.13.15 with HTTP; Fri, 21 Jul 2017 13:17:39 -0700 (PDT)
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Fri, 21 Jul 2017 16:17:39 -0400
Message-ID: <CACiOHGxYGdaPTAt07HFFGPEDhRC4PM3FZKk8Cwc0RgDN74qQrw@mail.gmail.com>
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0760cc94243c0554d98e99"
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: Fri, 21 Jul 2017 20:24:04 +0000
Cc: Major Kusanagi <majorkusanagibtc@gmail.com>
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: Fri, 21 Jul 2017 20:17:41 -0000
--94eb2c0760cc94243c0554d98e99
Content-Type: text/plain; charset="UTF-8"
If we have a problem with a UTXO set that is too large, seems like maybe
the fair way to approach it is to enforce a limit on the growth of the UTXO
set.
Miners would eventually be forced to generate blocks that are UTXO neutral
and would factor that into their algorithm for prioritizing transactions.
Users who wish to generate a lot of outputs would need to find a buddy with
lots of inputs to consolidate and create a tumble-bit with them. A market
would spring up that would charge people for creating UTXOs and pay them
for disposing of UTXOs.
On Fri, Jul 21, 2017 at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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".
>
> 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 the
> opinion it isn't worth the hassle.
>
> 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.
>
> --
> Lucas Clemente Vella
> lvella@gmail.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c0760cc94243c0554d98e99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If we have a problem with a UTXO set that is too large, se=
ems like maybe the fair way to approach it is to enforce a limit on the gro=
wth of the UTXO set.<div><br></div><div>Miners would eventually be forced t=
o generate blocks that are UTXO neutral and would factor that into their al=
gorithm for prioritizing transactions. Users who wish to generate a lot of =
outputs would need to find a buddy with lots of inputs to consolidate and c=
reate a tumble-bit with them. A market would spring up that would charge pe=
ople for creating UTXOs and pay them for disposing of UTXOs.</div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 21, 2017=
at 3:59 PM, Lucas Clemente Vella via bitcoin-dev <span dir=3D"ltr"><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev <span=
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div>[=
...] 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 solutio=
n is to limit UTXO growth, meaning bitcoins cannot last forever. This propo=
sed solution however does not prevent Bitcoin from lasting forever.<br></di=
v></div></div></div></blockquote><div>=C2=A0</div></div>Unless there is a l=
ogical contradiction in this phrasing, the proposed solution does not impro=
ves scalability:<br>=C2=A0- "Bitcoins lasting forever" implies &q=
uot;unscalable";<br>=C2=A0- "not prevent Bitcoin from lasting for=
ever" implies "Bitcoins lasting forever";<br></div><div clas=
s=3D"gmail_extra">=C2=A0- Thus: "not prevent Bitcoin from lasting fore=
ver" implies "unscalable".<br></div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">In practice, the only Bitcoin lost =
would be those whose owners forgot about or has lost the keys, because ever=
yone with a significant amount of Bitcoins would always shift them around b=
efore 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 actua=
lly lost/forgotten, but I have the opinion it isn't worth the hassle.<b=
r></div><div class=3D"gmail_extra"><br clear=3D"all"></div><div class=3D"gm=
ail_extra">As a side note, your estimate talks about block size, which is d=
etermines blockchain size, which can be "safely" pruned (if you a=
re not considering new nodes might want to join the network, in case the fu=
ll 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"HOE=
nZb"><font color=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"=
><font color=3D"#888888"><div class=3D"gmail_extra"><br>-- <br><div class=
=3D"m_-8969256773033653346gmail_signature">Lucas Clemente Vella<br><a href=
=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a></div>
</div></font></span></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--94eb2c0760cc94243c0554d98e99--
|
