From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6F69B14 for ; Fri, 21 Jul 2017 20:00:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 13A4E3D9 for ; Fri, 21 Jul 2017 20:00:04 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id l200so27116773lfb.2 for ; Fri, 21 Jul 2017 13:00:03 -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=X32iI9zQRmo62FC5XJUZyhiV2ppqmEhkpQC92zbK7Ts=; b=mMNJgz/XR9WQiOMtI+q7XdfHEJCLKWMOElStIBxr+6cP3Vb/vzHLcK2jOIN+4QrOxo MejgLz7F/p4r/Kn29iFpYgpWu2V3s8TsXk8ytlJu4eaov0DNyxvM3+m0csKlQwu3jR4e 0v4KmgCTrh6Coq+kfV/w1z+E0jWBw2TBEWNHeFXAQD9Lvtkc1lte9dBchE+43f20s0Gn tWStr5u1jmcS/k17ZeIrlUnPHRWOrmRM7DDdT+i02ytNu2I3J2VoqZ6S+KACQBUvG5Do RQeEQMG+vOCyUnEf2Qr3JHw8VGCloG0Q7s+cRR0dtivtpSySIBQBVBHvcWzgIlujT5Y4 w6Qw== 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=X32iI9zQRmo62FC5XJUZyhiV2ppqmEhkpQC92zbK7Ts=; b=cTrjrNuaLQG4AVUWA4jPY6a346U4SVKDpqXvqa+fgKG7cDcQoOZf+HQzYN9dK5xiF9 Ocr4JaMSG/wO27XKW4bYS8vFyO1q6+671PtnCkJFDud2DmsmqlHRdFp9dS9NQ0zGvgjh +HT5W7F4Sqaoxjp5cJDiGh5vEp19tGULjSh0pTg5wshxlFPglceNjYQigzgd82nCmF4X 5tNHFEtpXCmwO+KcDTN7P0SiHwTwKyo+WM6XxBd5caBDFJH155S4gujxQqjsU8PZonzX ghFUjWtJqnAJPJwjRcsEf4GSpumO8MdVxtIjCZukqrHOaiLEkp1S8iUdAXbXF//ht20T apjw== X-Gm-Message-State: AIVw1133lT9+bbosOln5D6G5iHNcWYKnUXpm7TKuY0ReasFzJ09ZKSsU Tq7kmXSw4bv+RqRpQsKScjbUjZWmkQ== X-Received: by 10.46.84.72 with SMTP id y8mr2941511ljd.101.1500667202523; Fri, 21 Jul 2017 13:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.43.208 with HTTP; Fri, 21 Jul 2017 12:59:42 -0700 (PDT) In-Reply-To: References: From: Lucas Clemente Vella Date: Fri, 21 Jul 2017 16:59:42 -0300 Message-ID: To: Major Kusanagi , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045fb62e8857640554d94f5f" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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:05:35 +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: Fri, 21 Jul 2017 20:00:04 -0000 --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
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 gr= owth, meaning bitcoins cannot last forever. This proposed solution however = does not prevent Bitcoin from lasting forever.
<= /blockquote>
=C2=A0
Unless there is a logical contradiction = in this phrasing, the proposed solution does not improves scalability:
= =C2=A0- "Bitcoins lasting forever" implies "unscalable"= ;
=C2=A0- "not prevent Bitcoin from lasting forever" implies &= quot;Bitcoins lasting forever";
= =C2=A0- Thus: "not prevent Bitcoin from lasting forever" implies = "unscalable".

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

As a si= de note, your estimate talks about block size, which is determines blockcha= in 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 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.

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