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 53B31B14 for ; Fri, 21 Jul 2017 19:58:13 +0000 (UTC) X-Greylist: delayed 00:05:01 by SQLgrey-1.7.6 Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DEC163D9 for ; Fri, 21 Jul 2017 19:58:11 +0000 (UTC) X-AuditID: 1209190f-8fdff70000000f46-1f-59725ba5fbe2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 88.7A.03910.5AB52795; Fri, 21 Jul 2017 15:53:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6LJr807032425 for ; Fri, 21 Jul 2017 15:53:08 -0400 Received: from mail-yb0-f170.google.com (mail-yb0-f170.google.com [209.85.213.170]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6LJr6nH009457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 21 Jul 2017 15:53:07 -0400 Received: by mail-yb0-f170.google.com with SMTP id w187so14333862ybc.0 for ; Fri, 21 Jul 2017 12:53:07 -0700 (PDT) X-Gm-Message-State: AIVw111rWWr0J32S0hKyF8x+eY56/saeg0nBLqrAgtXCcTd3ERyh9AUq S3WWR2xkSAOSoJeOoi3KZnI1FccTpQ== X-Received: by 10.37.164.34 with SMTP id f31mr6964426ybi.317.1500666786189; Fri, 21 Jul 2017 12:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.28.133 with HTTP; Fri, 21 Jul 2017 12:52:45 -0700 (PDT) In-Reply-To: References: From: Jeremy Date: Fri, 21 Jul 2017 15:52:45 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Major Kusanagi , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045c6e54b7a1cc0554d936be" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsUixCmqrLs0uijS4PEEHYum17YOjB6/f0xm DGCM4rJJSc3JLEst0rdL4MqY0aVacLqkYsezO+wNjK/juxg5OSQETCTOv1nL0sXIxSEksJhJ omXRK0YI5y6jxKquj8wQzhcmiZXH3kCVLWKUON77lR2iP19i3of5UHaxRN+3DiYQm1dAUOLk zCcsILaQgJfE+52nwGxOgUCJvc82sEPEAySmbD7J2sXIwcEmICfx4ZcpSJhFQFVizrzFTCBh CYFEiYYDPBATAyR+P//OCmILCzhILO3fCjZRRKBWorvjHQtIObOAj8TtNaUTGIVmIblhFkIG JMwsoCnRuv03O4StLbFs4WtmCFtDYsGdfYzI4gsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbp mujlZpbopaaUbmIER4Ek/w7GOQ3ehxgFOBiVeHgNWIoihVgTy4orcw8xSnIwKYnyaloBhfiS 8lMqMxKLM+KLSnNSiw8xSnAwK4nwfgkDyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NT C1KLYLIyHBxKErzuUUCNgkWp6akVaZk5JQhpJg5OkOE8QMPNQGp4iwsSc4sz0yHypxgDOf40 rP3CxHHlyjogOeXAdiC5acbPb0wch36f+M7EcQxMNn3/+J1JiCUvPy9VSpxXFWSQAMigjNI8 uF2gJHgx9OqqV4ziQK8L8xaDVPEAEyjctldAhzABHfLIrQDkkJJEhJRUA+PcDxcMLj0I3B17 Pj9JSDRpD8fzZ4q7t3/YFXOoxaf0i9zjEJ/qO3n1F20m5d7oOqyhNLv0jVme+iupl03Zdw/V lZzjXHO0Q2DOdadovtoHEideRn2tvbyntauaLewSg8MLv/l2KkWT206cdOlqtRUofv9jSnPh u2vKLQ+mpfe6Ts3JsWP490KJpTgj0VCLuag4EQDh7t0IXQMAAA== X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 19:58:13 -0000 --f403045c6e54b7a1cc0554d936be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Major, I think that you'll enjoy Peter Todd's blogpost on TXO commitments[1]. It has a better scalability improvement with fewer negative consequence. Best, Jeremy [1] https://petertodd.org/2016/delayed-txo-commitments -- @JeremyRubin On Fri, Jul 21, 2017 at 3:28 PM, Major Kusanagi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > I have a scaling solution idea that I would be interested in getting some > feedback on. I=E2=80=99m new to the mailing list and have not been in the= Bitcoin > space as long as some have been, so I don=E2=80=99t know if anyone has th= ought of > this idea. > > Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO > growth. Current scaling solutions like Segregated Witness, Lighting > Network, and larger blocks does not address this issue. As more and more > blocks are added to the block chain the size of the UTXO set that miners > have to maintain continues to grow. This is the case even if the block si= ze > were to remain at 1 megabyte. There is no way out of solving this > fundamental scaling problem other then to limit the maximum size of the > UTXO set. > > The following soft fork solution is proposed. Any UTXO that is not spent > within a set number of blocks is considered invalid. What this means for > miners and nodes in the Bitcoin network is that they only have to ever > store that set number of blocks. In others words the block chain will nev= er > be larger then the set number of blocks and the size of the block chain i= s > capped. > > But what this means for users is that bitcoins that have not been spent > for a long time are =E2=80=9Clost=E2=80=9D forever. This proposed solutio= n is likely a > difficult thing for Bitcoin users to accept. What Bitcoin users will > experience is that all of a sudden their bitcoins are spendable one momen= t > and the next moment they are not. The experience that they get is that al= l > of a sudden their old bitcoins are gone forever. > > The solution can be improved by adding this new mechanism to Bitcoin, tha= t > I will call luster. UTXO=E2=80=99s that are less then X blocks old has no= t lost any > luster and have a luster value of 1. As UTXO=E2=80=99s get older, the lus= ter value > will continuously decrease until the UTXO=E2=80=99s become Z blocks old (= where Z > > X), and has lost all it=E2=80=99s luster and have a luster value of 0. UT= XO=E2=80=99s that > are in between X and Z blocks old have a luster value between 0 and 1. Th= e > luster value is then used to compute the amount of bitcoins that must be > burned in order for a transaction with that UTXO to be included in a bloc= k. > So for example, a UTXO with a luster value of 0.5 must burn at least 50 > percent of its bitcoin value, a UTXO with a luster value of 0.25 must bur= n > at least 75 percent of its bitcoin value, and a UTXO with a luster value = of > 0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that > have a luster value of 0 means it has no monetary value, and it would be > safe for bitcoins nodes to drop those UTXOs from the set they maintain. > > The idea is that coins that are continuously being used in Bitcoin econom= y > will never lose it=E2=80=99s luster. But coins that are old and not circu= lating > will start to lose its luster up until all luster is lost and they become > valueless. Or they reenter the economy and regains all its luster. > > But at what point should coins start losing their luster? A goal would be > that we want to minimize the scenarios of when coins start losing their > luster. One reasonable answer is that coins should only starting losing i= ts > luster after the lifespan of the average human. The idea being that a > person will eventually have to spend all his coins before he dies, > otherwise it will get lost anyways (assuming that only the dying person h= as > the ability to spend those coins). Otherwise there are few cases where a > person would never spend their bitcoins in there human life time. One > example is in the case of inheritance where a dying person does not want = to > spend his remaining coins and have another person take them over. But wit= h > this propose scaling solution, coins can be stilled inherited, but it wou= ld > have to be an on-chain inheritance. The longest lifespan of a human > currently is about 120 years old. So a blockchain that stores the last 15= 0 > years of history seems like one reasonable option. > > Then the question of how large blocks should be is simply a matter of wha= t > is the disk size requirement for a full node. For simplicity, assuming th= at > a block is created every 10 minute, the blockchain size in terabyte can b= e > express as the following. > blockSize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize TB > > Example values: > blockSize =3D 1MB, years =3D 150 -> blockchainSize =3D 7.884 TB > blockSize =3D 2MB, years =3D 150 -> blockchainSize =3D 15.768 TB > > So if we don=E2=80=99t want the block chain to be bigger then 8 TB, then = we should > have a block size of 1 MB. If we don=E2=80=99t want the block chain to be= bigger > then 16 TB, then we should have a block size of 2 MB and so on. The idea = is > that base on how cheap disk space gets, we can adjust the target max bloc= k > chain size and the block size accordingly. > > I believe that this proposal is a good solution to the UTXO growth > problem. The proposal being a soft fork is a big plus. It also keeps the > block chain size finite even if given a infinite amount of time. But ther= e > are other things to considered, like how best should wallet software hand= le > this? How can this work with sidechains? More thought would need to be pu= t > into this. 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 onl= y > solution is to limit UTXO growth, meaning bitcoins cannot last forever. > This proposed solution however does not prevent Bitcoin from lasting > forever. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045c6e54b7a1cc0554d936be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Major,

I think that you'll enjoy Peter To= dd's blogpost on TXO commitments[1]. It has a better scalability improv= ement with fewer negative consequence.

Best,

Jeremy<= br>



[1] https://petertodd.org/2016= /delayed-txo-commitments


On Fri, Jul 21, 2017 at 3:28 PM, Major Kusan= agi via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
Hi all,

I have a scaling solution idea t= hat I would be interested in getting some feedback on. I=E2=80=99m new to t= he mailing list and have not been in the Bitcoin space as long as some have= been, so I don=E2=80=99t know if anyone has thought of this idea.

Arguably the biggest scaling problem for Bitcoin is the un= bounded UTXO growth. Current scaling solutions like Segregated Witness, Lig= hting Network, and larger blocks does not address this issue. As more and m= ore blocks are added to the block chain the size of the UTXO set that miner= s have to maintain continues to grow. This is the case even if the block si= ze were to remain at 1 megabyte. There is no way out of solving this fundam= ental scaling problem other then to limit the maximum size of the UTXO set.=

The following soft fork solution is proposed. Any= UTXO that is not spent within a set number of blocks is considered invalid= . What this means for miners and nodes in the Bitcoin network is that they = only have to ever store that set number of blocks. In others words the bloc= k chain will never be larger then the set number of blocks and the size of = the block chain is capped.

But what this means for= users is that bitcoins that have not been spent for a long time are =E2=80= =9Clost=E2=80=9D forever. This proposed solution is likely a difficult thin= g for Bitcoin users to accept. What Bitcoin users will experience is that a= ll of a sudden their bitcoins are spendable one moment and the next moment = they are not. The experience that they get is that all of a sudden their ol= d bitcoins are gone forever.

The solution can be i= mproved by adding this new mechanism to Bitcoin, that I will call luster. U= TXO=E2=80=99s that are less then X blocks old has not lost any luster and h= ave a luster value of 1. As UTXO=E2=80=99s get older, the luster value will= continuously decrease until the UTXO=E2=80=99s become Z blocks old (where = Z > X), and has lost all it=E2=80=99s luster and have a luster value of = 0. UTXO=E2=80=99s that are in between X and Z blocks old have a luster valu= e between 0 and 1. The luster value is then used to compute the amount of b= itcoins that must be burned in order for a transaction with that UTXO to be= included in a block. So for example, a UTXO with a luster value of 0.5 mus= t burn at least 50 percent of its bitcoin value, a UTXO with a luster value= of 0.25 must burn at least 75 percent of its bitcoin value, and a UTXO wit= h a luster value of 0 must burn 100 percent of its bitcoin value. Thus the = coins/UTXOs that have a luster value of 0 means it has no monetary value, a= nd it would be safe for bitcoins nodes to drop those UTXOs from the set the= y maintain.

The idea is that coins that are contin= uously being used in Bitcoin economy will never lose it=E2=80=99s luster. B= ut coins that are old and not circulating will start to lose its luster up = until all luster is lost and they become valueless. Or they reenter the eco= nomy and regains all its luster.

But at what point= should coins start losing their luster? A goal would be that we want to mi= nimize the scenarios of when coins start losing their luster. One reasonabl= e answer is that coins should only starting losing its luster after the lif= espan of the average human. The idea being that a person will eventually ha= ve to spend all his coins before he dies, otherwise it will get lost anyway= s (assuming that only the dying person has the ability to spend those coins= ). Otherwise there are few cases where a person would never spend their bit= coins in there human life time. One example is in the case of inheritance w= here a dying person does not want to spend his remaining coins and have ano= ther person take them over. But with this propose scaling solution, coins c= an be stilled inherited, but it would have to be an on-chain inheritance. T= he longest lifespan of a human currently is about 120 years old. So a block= chain that stores the last 150 years of history seems like one reasonable o= ption.

Then the question of how large blocks shoul= d be is simply a matter of what is the disk size requirement for a full nod= e. For simplicity, assuming that a block is created every 10 minute, the bl= ockchain size in terabyte can be express as the following.
blockS= ize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize TB

=
Example values:
blockSize =3D 1MB, years =3D 150 ->= blockchainSize =3D 7.884 TB
blockSize =3D 2MB, years =3D 150 -&g= t; blockchainSize =3D 15.768 TB

So if we don=E2=80= =99t want the block chain to be bigger then 8 TB, then we should have a blo= ck size of 1 MB. If we don=E2=80=99t want the block chain to be bigger then= 16 TB, then we should have a block size of 2 MB and so on. The idea is tha= t base on how cheap disk space gets, we can adjust the target max block cha= in size and the block size accordingly.

I believe = that this proposal is a good solution to the UTXO growth problem. The propo= sal being a soft fork is a big plus. It also keeps the block chain size fin= ite even if given a infinite amount of time. But there are other things to = considered, like how best should wallet software handle this? How can this = work with sidechains? More thought would need to be put into this. But the = fact is that if we want to make bitcoins last forever, we have the accept u= nbounded 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.

=

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--f403045c6e54b7a1cc0554d936be--