path: root/b7/8e6c3f1ba2c37ab4df9d8b8aa2074d41a5a396

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 53B31B14
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 15:53:07 -0400
Received: by mail-yb0-f170.google.com with SMTP id w187so14333862ybc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 21 Jul 2017 15:52:45 -0400
X-Gmail-Original-Message-ID: <CAD5xwhiYfGcH6Bt2ESFAoR7pt9-vC1zXio3pk1X-h60m_QMqZQ@mail.gmail.com>
Message-ID: <CAD5xwhiYfGcH6Bt2ESFAoR7pt9-vC1zXio3pk1X-h60m_QMqZQ@mail.gmail.com>
To: Major Kusanagi <majorkusanagibtc@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Hi Major,<br><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">I think that you&#39;ll enjoy Peter To=
dd&#39;s blogpost on TXO commitments[1]. It has a better scalability improv=
ement with fewer negative consequence.<br><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">Best,<br><br></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy<=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br><br><br>[1] <a href=3D"htt=
ps://petertodd.org/2016/delayed-txo-commitments">https://petertodd.org/2016=
/delayed-txo-commitments</a><br></div></div><div class=3D"gmail_extra"><br =
clear=3D"all"><div><br clear=3D"all"><div><div class=3D"gmail_signature" da=
ta-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://=
twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https=
://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Fri, Jul 21, 2017 at 3:28 PM, Major Kusan=
agi via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div=
><div>Hi all,<br></div><div><br></div><div>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.</div><di=
v><br></div><div>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.=
</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 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.</div><div><br></div><div>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.</div><div><br></div><div>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 &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 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>blockS=
ize MB * 6 * 24 * 365 * years /1000000 =3D blockchainSize TB</div><div><br>=
</div><div>Example values:</div><div>blockSize =3D 1MB, years =3D 150 -&gt;=
 blockchainSize =3D 7.884 TB</div><div>blockSize =3D 2MB, years =3D 150 -&g=
t; blockchainSize =3D 15.768 TB</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div>=
</div>
</div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--f403045c6e54b7a1cc0554d936be--