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 the
> opinion it isn't worth the hassle.
>

Exactly. That’s the whole idea. Why bother have nodes store UTXO’s 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’ve address this with the checkpoint mechanism in my reply to
Jameson.



> --
> Lucas Clemente Vella
> lvella@gmail.com
>