Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 565D088A for ; Fri, 21 Jul 2017 19:29:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38EBE201 for ; Fri, 21 Jul 2017 19:29:09 +0000 (UTC) Received: by mail-wm0-f49.google.com with SMTP id w191so21755176wmw.1 for ; Fri, 21 Jul 2017 12:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hLcAXMiUJWmuZc++JHnZ3CTd0DeLHV64/dEvdIqzS38=; b=RP6+XtXEcn4U7ft4c6dFGnVpfs6IcI/lNK6qaxhN346b540p+drqb9Q/MArVj3hmOg I2ThRGWiKHbo5AS+93LWP78xv/LtR3IInye5SyS5jPYbY16Wes+8sqbD/DHSW6WTWz2C dAjVBvsU9xyKHy1opDkYzXxwp26L3IQKRA7UXd1+rIzkdu7tIGyMXsSMijb6Z4+t3lFW NjMngshd7gD28D5WP8v4PhS4yw+uEi1BGcpaNw3qWSGlvSH83VVXvtc+N+Kf88Sh0Z5g GU7Lbr49PTdtWrvvy1CfHdmW1MplKrWDAijTQ4+yXZrHo9yjCNY+p4GKNN9HEqbMEHkn osnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hLcAXMiUJWmuZc++JHnZ3CTd0DeLHV64/dEvdIqzS38=; b=lj8sYt8CCQ5BnmPfzc8BPpl6D2uQA+Vio3cLGD5J8/7apjVB/jEOZjKPmkRmsji+9h q0xwB3r13g1Wn2pVMJ5WqlYXO5r1PxemlNP1lpCggYYh/zgWL3Zf6b72PXs5cWHGLNhV K/JbbnZIEm9d3nNP9ruOLzr2HY4FIZklVFgHcY6Fjo5xYqXxsrclhjPtlJBwsH3m1e6C mQ93oF0n8g0tTQzUZK2tqA69QkpGaJXc1azh6Qo+YJxE7u9sGUdIdY/81BsTP7ZJZ0K6 m815fl7nJBAsjvMQj5faMHcIViGxxTOC6BHiBfwZFnWlHoeULoDbC7/DRUhXWC9vyifm OA9A== X-Gm-Message-State: AIVw111Rh68WusCZ8G/WBEQblCTXW6pUeBAAD228avHsVpkS7gDpmZ54 K3z1UmyG1xKZSeyNk3nsnl3op0Dpy+E4 X-Received: by 10.80.143.163 with SMTP id y32mr6848156edy.103.1500665347629; Fri, 21 Jul 2017 12:29:07 -0700 (PDT) MIME-Version: 1.0 From: Major Kusanagi Date: Fri, 21 Jul 2017 19:28:57 +0000 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="f403045c825af8e8df0554d8e0bf" 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 19:32:37 +0000 Subject: [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:29:10 -0000 --f403045c825af8e8df0554d8e0bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 B= itcoin space as long as some have been, so I don=E2=80=99t know if anyone has thou= ght 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 size 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 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 l= ikely a difficult thing for Bitcoin users to accept. What Bitcoin users will experience is that all 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 old bitcoins are gone forever. The solution can be improved by adding this new mechanism to Bitcoin, that I will call luster. UTXO=E2=80=99s that are less then X blocks old has not = lost any luster and have a luster value of 1. As UTXO=E2=80=99s get older, the luste= r value will continuously decrease until the UTXO=E2=80=99s become Z blocks old (wh= ere 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 value between 0 and 1. The 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 block. 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 burn 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 economy will never lose it=E2=80=99s luster. But coins that are old and not circula= ting 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 its 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 has 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 with this propose scaling solution, coins can be stilled inherited, but it would 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 150 years of history seems like one reasonable option. Then the question of how large blocks should be is simply a matter of what is the disk size requirement for a full node. For simplicity, assuming that a block is created every 10 minute, the blockchain size in terabyte can be 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 b= igger 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 block 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 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 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. --f403045c825af8e8df0554d8e0bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have a scaling s= olution 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 l= ong as some have been, so I don=E2=80=99t know if anyone has thought of thi= s idea.

Arguably the biggest scaling problem for B= itcoin is the unbounded UTXO growth. Current scaling solutions like Segrega= ted Witness, Lighting Network, and larger blocks does not address this issu= e. As more and more blocks are added to the block chain the size of the UTX= O set that miners have to maintain continues to grow. This is the case even= if the block size were to remain at 1 megabyte. There is no way out of sol= ving 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 co= nsidered invalid. What this means for miners and nodes in the Bitcoin netwo= rk is that they only have to ever store that set number of blocks. In other= s words the block chain will never be larger then the set number of blocks = and the size of the block chain is capped.

But wha= t 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 thing for Bitcoin users to accept. What Bitcoin users will expe= rience is that all 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 old bitcoins are gone forever.

The s= olution can be improved by adding this new mechanism to Bitcoin, that I wil= l call luster. UTXO=E2=80=99s that are less then X blocks old has not lost = any luster and have a luster value of 1. As UTXO=E2=80=99s get older, the l= uster value will continuously decrease until the UTXO=E2=80=99s become Z bl= ocks 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 ha= ve a luster value between 0 and 1. The 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 block. So for example, a UTXO with a luster = value of 0.5 must burn at least 50 percent of its bitcoin value, a UTXO wit= h a luster value of 0.25 must burn 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 m= onetary 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 economy will never lose it=E2= =80=99s luster. But coins that are old and not circulating will start to lo= se its luster up until all luster is lost and they become valueless. Or the= y reenter the economy and regains all its luster.

= But at what point should coins start losing their luster? A goal would be t= hat we want to minimize the scenarios of when coins start losing their lust= er. One reasonable answer is that coins should only starting losing its lus= ter after the lifespan of the average human. The idea being that a person w= ill eventually have to spend all his coins before he dies, otherwise it wil= l get lost anyways (assuming that only the dying person has the ability to = spend those coins). Otherwise there are few cases where a person would neve= r 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 c= oins and have another person take them over. But with this propose scaling = solution, coins can be stilled inherited, but it would have to be an on-cha= in inheritance. The longest lifespan of a human currently is about 120 year= s old. So a blockchain that stores the last 150 years of history seems like= one reasonable option.

Then the question of how l= arge blocks should be is simply a matter of what is the disk size requireme= nt for a full node. For simplicity, assuming that a block is created every = 10 minute, the blockchain size in terabyte can be express as the following.=
blockSize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize = TB

Example values:
blockSize =3D 1MB, ye= ars =3D 150 -> blockchainSize =3D 7.884 TB
blockSize =3D 2MB, = years =3D 150 -> blockchainSize =3D 15.768 TB

S= o 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 tar= get max block chain size and the block size accordingly.

I believe that this proposal is a good solution to the UTXO growth p= roblem. The proposal being a soft fork is a big plus. It also keeps the blo= ck chain size finite even if given a infinite amount of time. But there are= other things to considered, like how best should wallet software handle th= is? How can this work with sidechains? More thought would need to be put in= to 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 only sol= ution is to limit UTXO growth, meaning bitcoins cannot last forever. This p= roposed solution however does not prevent Bitcoin from lasting forever.

--f403045c825af8e8df0554d8e0bf--