path: root/5b/56a0712a6fa6de74eb8d04f4dde4084fec2e6b

Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 861FAB14
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 19:54:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
	[209.85.218.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5FDC73CD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 19:54:27 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id e124so25974849oig.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Jul 2017 12:54:27 -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=k8LGlXYLovxoqcXsZcZYAzlQBLHS+6JuJ23+vkrejvw=;
	b=DvEIhzS8X5ruIvacdN6I0dl7XjkYIth/Kdau4ojepF0X5zyRU3zVy7pw/BxLR3Gf5Y
	P6n1kecMuoN/HLD9sszgkrVrUyrleUnEQJFiO5jdKAnhkob0tpTr4IDXhnnyVqMkm3z4
	hKrFBbV+ubHLb37Y5ufUvNfhCNYJCNqS/eH5CoVyUl1+a4xN+s56YeDfHkLSlFcZYupJ
	1uQOWUTUxicvvUE+akee3sN5T5fW5Be6HXgt5rAWP3y5BKovhZQ50F/wSEurRkW0ph8b
	wsXuzthqb5v62LCe1MmeDtzBtvFN2L0ZPq/Q+AIXZ0TMpRzWuxHwz3grOhmC8qkKJGeF
	O6+w==
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=k8LGlXYLovxoqcXsZcZYAzlQBLHS+6JuJ23+vkrejvw=;
	b=dioROsbRZkmeYADJemU13K67JwjZYVPQjcllBkgoeH6NhjxWZSqGpMqeeJQQeU3Lhv
	3db0ubFW9k+eq7Ip1P30fxeXwEwJdp7cZwt5OI12tAoVWgiaR4vNPu15Uy943GsdizwQ
	Jcx/nkDGSlX84b6ulYYScI87Dy7cg4t/0DmNnStGnOjYhDk4DBCFzPyyBgRnPgwHuD9+
	TNSHZBZ3KTHq1Z+M3LcL4ad9Kn/BkrRy3eYTLctBUyAdkdQGWBacfYFFU+q7Ktf0REph
	E+WZNc6m2vrRHDE218w9d+sy19ODoe1CaMOdGyRBLMoN18FbjWqgGcEFeVuXsO7DNS3E
	NtXw==
X-Gm-Message-State: AIVw1115gOFhloc8imvyfz/idYWgiADLTBCzgUXQl8XovZ4s4Mr0FzBH
	lDtJckaHEvLz/U7AkUwkBYA/z55P2g==
X-Received: by 10.202.180.4 with SMTP id d4mr2437520oif.188.1500666866665;
	Fri, 21 Jul 2017 12:54:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.175.76 with HTTP; Fri, 21 Jul 2017 12:54:26 -0700 (PDT)
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Fri, 21 Jul 2017 15:54:26 -0400
Message-ID: <CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com>
To: Major Kusanagi <majorkusanagibtc@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113d4232838f2f0554d93b5d"
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
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:54:28 -0000

--001a113d4232838f2f0554d93b5d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sounds like demurrage to me, which has been implemented in other
cryptocurrencies such as Freicoin - http://freico.in/

While it's an interesting to apply this line of thinking from a scaling
perspective, I suspect most would find it untenable from a monetary policy
perspective.

You have touched on a scaling issue, the cost of node operation, that I
think is really the root cause of a lot of the debate. Thus even if your
proposal was implemented, we'd still have to solve the problem of finding a
consensus for CONOP.

I think you may have misapplied your logic to the total size of the
blockchain, however. Are you suggesting that pruning of the old UTXOs would
also enable pruning of old blocks from all nodes? Those things aren't
really related, plus someone would still have to keep old blocks around in
order to facilitate new nodes syncing from genesis.

- Jameson

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
>
>

--001a113d4232838f2f0554d93b5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sounds like demurrage to me, which has been implemented in=
 other cryptocurrencies such as Freicoin -=C2=A0<a href=3D"http://freico.in=
/">http://freico.in/</a><div><br></div><div>While it&#39;s an interesting t=
o apply this line of thinking from a scaling perspective, I suspect most wo=
uld find it untenable from a monetary policy perspective.</div><div><br></d=
iv><div>You have touched on a scaling issue, the cost of node operation, th=
at I think is really the root cause of a lot of the debate. Thus even if yo=
ur proposal was implemented, we&#39;d still have to solve the problem of fi=
nding a consensus for CONOP.</div><div><br></div><div>I think you may have =
misapplied your logic to the total size of the blockchain, however. Are you=
 suggesting that pruning of the old UTXOs would also enable pruning of old =
blocks from all nodes? Those things aren&#39;t really related, plus someone=
 would still have to keep old blocks around in order to facilitate new node=
s syncing from genesis.</div><div><br></div><div>- Jameson</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 21, 2017 a=
t 3:28 PM, Major Kusanagi via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div><div><div><div>Hi all,<br></div><div><br></div><div>I have a s=
caling 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 spac=
e as long as some have been, so I don=E2=80=99t know if anyone has thought =
of this idea.</div><div><br></div><div>Arguably the biggest scaling problem=
 for Bitcoin is the unbounded UTXO growth. Current scaling solutions like S=
egregated Witness, Lighting Network, and larger blocks does not address thi=
s issue. As more and more blocks are added to the block chain the size of t=
he UTXO set that miners have to maintain continues to grow. This is the cas=
e 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.</div><div><br></div><div>The following soft fork sol=
ution 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 b=
locks and the size of the block chain is capped.</div><div><br></div><div>B=
ut 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 wil=
l 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.</div><div><br></div><div=
>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 luster value will continuously decrease until the UTXO=E2=80=99s becom=
e Z blocks old (where Z &gt; X), and has lost all it=E2=80=99s luster and h=
ave 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 c=
ompute the amount of bitcoins that must be burned in order for a transactio=
n with that UTXO to be included in a block. So for example, a UTXO with a l=
uster value of 0.5 must burn at least 50 percent of its bitcoin value, a UT=
XO 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 bi=
tcoin value. Thus the coins/UTXOs that have a luster value of 0 means it ha=
s no monetary 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 lose its luster up until all luster is lost and they become valueless. O=
r they 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 that we want to minimize the scenarios of when coins start losing their=
 luster. One reasonable answer is that coins should only starting losing it=
s luster after the lifespan of the average human. The idea being that a per=
son will eventually have to spend all his coins before he dies, otherwise i=
t will get lost anyways (assuming that only the dying person has the abilit=
y 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 remain=
ing coins and have another person take them over. But with this propose sca=
ling solution, coins can be stilled inherited, but it would have to be an o=
n-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.</div><div><br></div><div>Then the question of =
how large blocks should be is simply a matter of what is the disk size requ=
irement for a full node. For simplicity, assuming that a block is created e=
very 10 minute, the blockchain size in terabyte can be express as the follo=
wing.</div><div>blockSize MB * 6 * 24 * 365 * years /1000000 =3D blockchain=
Size TB</div><div><br></div><div>Example values:</div><div>blockSize =3D 1M=
B, years =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>So if we don=E2=80=99t want the block chain to be bigger then 8 TB, the=
n we should have a block size of 1 MB. If we don=E2=80=99t want the block c=
hain 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 th=
e target max block chain size and the block size accordingly.</div><div><br=
></div><div>I believe that this proposal is a good solution to the UTXO gro=
wth problem. The proposal being a soft fork is a big plus. It also keeps th=
e 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 p=
ut 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. T=
his 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>

--001a113d4232838f2f0554d93b5d--