Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 29806258 for ; 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 ; Sat, 22 Jul 2017 06:45:56 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id v139so487630wmv.0 for ; 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: References: From: Major Kusanagi Date: Fri, 21 Jul 2017 23:45:54 -0700 Message-ID: To: Lucas Clemente Vella , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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


On Fri, Jul 21, 2017 at 12:59 PM, Lucas Clemente Vella <lvella@gmail.co= m> wrote:
20= 17-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org>:
[...] 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.
=
=C2=A0
Unless there is a logical contrad= iction in this phrasing, the proposed solution does not improves scalabilit= y:
=C2=A0- "Bitcoins lasting forever" implies "unscalable= ";
=C2=A0- "not prevent Bitcoin from lasting forever" imp= lies "Bitcoins lasting forever";
=C2=A0- Thus: "not prevent Bitcoin from lasting forever" impl= ies "unscalable".

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.

=C2=A0
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.

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.
=C2=A0

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.

I believe I=E2=80=99ve address this with the checkpoint= mechanism in my reply to Jameson.

=C2=A0
= --
Lucas Cle= mente Vella
lvella= @gmail.com

--94eb2c0e489a5def2e0554e2553e--