path: root/9f/49646ad7f79d0f44873f2c4d99a08e35e3c4d4

Return-Path: <majorkusanagibtc@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 565D088A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 19:29:09 +0000 (UTC)
Received: by mail-wm0-f49.google.com with SMTP id w191so21755176wmw.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <majorkusanagibtc@gmail.com>
Date: Fri, 21 Jul 2017 19:28:57 +0000
Message-ID: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div><div><div><div>Hi all,<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 &gt; 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.</div><div><br></div><div>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.</div><div><br></div><div>=
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.</div><div><br></div><div>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.=
</div><div>blockSize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize =
TB</div><div><br></div><div>Example values:</div><div>blockSize =3D 1MB, ye=
ars =3D 150 -&gt; blockchainSize =3D 7.884 TB</div><div>blockSize =3D 2MB, =
years =3D 150 -&gt; blockchainSize =3D 15.768 TB</div><div><br></div><div>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.</div><div><br></di=
v><div>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.</di=
v><div><br></div></div>
</div></div>

--f403045c825af8e8df0554d8e0bf--