MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Precedence: list

--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=
">&lt;<a href=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.co=
m</a>&gt;</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>&gt;</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- &quot;Bitcoins lasting forever&quot; implies &quot;unscalable=
&quot;;<br>=C2=A0- &quot;not prevent Bitcoin from lasting forever&quot; imp=
lies &quot;Bitcoins lasting forever&quot;;<br></div><div class=3D"gmail_ext=
ra">=C2=A0- Thus: &quot;not prevent Bitcoin from lasting forever&quot; impl=
ies &quot;unscalable&quot;.</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&#39;t bother to move my Bitcoins every 10 years). I don&#3=
9;t know how to estimate the percentage of UTXO is actually lost/forgotten,=
 but I have the opinion it isn&#39;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 &quot;safely&quot; 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&#39;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--