MIME-Version: 1.0
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
From: Lucas Clemente Vella <lvella@gmail.com>
Date: Fri, 21 Jul 2017 16:59:42 -0300
Message-ID: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
To: Major Kusanagi <majorkusanagibtc@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045fb62e8857640554d94f5f"
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Precedence: list

--f403045fb62e8857640554d94f5f
Content-Type: text/plain; charset="UTF-8"

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

--f403045fb62e8857640554d94f5f
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">2017=
-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"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(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 solution is to limit UTXO gr=
owth, meaning bitcoins cannot last forever. This proposed solution however =
does not prevent Bitcoin from lasting forever.<br></div></div></div></div><=
/blockquote><div>=C2=A0</div></div>Unless there is a logical contradiction =
in this phrasing, the proposed solution does not improves scalability:<br>=
=C2=A0- &quot;Bitcoins lasting forever&quot; implies &quot;unscalable&quot;=
;<br>=C2=A0- &quot;not prevent Bitcoin from lasting forever&quot; implies &=
quot;Bitcoins lasting forever&quot;;<br></div><div class=3D"gmail_extra">=
=C2=A0- Thus: &quot;not prevent Bitcoin from lasting forever&quot; implies =
&quot;unscalable&quot;.<br></div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">In practice, the only Bitcoin lost would be those who=
se owners forgot about or has lost the keys, because everyone with a signif=
icant 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&#=
39;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.<br></div><div class=
=3D"gmail_extra"><br clear=3D"all"></div><div class=3D"gmail_extra">As a si=
de note, your estimate talks about block size, which is determines blockcha=
in size, 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 need=
ed to be stored somewhere). But UTXO size, albeit related to the full block=
chain size, is the part that currently can not be safely pruned, so I don&#=
39;t see the relevance of the analysis.<br></div><div class=3D"gmail_extra"=
><br>-- <br><div class=3D"gmail_signature">Lucas Clemente Vella<br><a href=
=3D"mailto:lvella@gmail.com" target=3D"_blank">lvella@gmail.com</a></div>
</div></div>

--f403045fb62e8857640554d94f5f--