path: root/63/70c6204db99eaa0c236ed6e5c5c2a3f5ec48bd

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EA75A7C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Aug 2017 14:26:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E2E00484
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Aug 2017 14:26:36 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id u139so83273544qka.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 21 Aug 2017 07:26:36 -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
	:cc; bh=HWB/+zkBFfA0uVxhjkuTP6coi32O3YnxhPk+GJo4rq4=;
	b=Emf0jMQV0pllZUP9AqNLOci6gl4CSXcVSZkdF8He2HRDp8b/J3AT69B6qFmEVb1KdG
	tdfW5aFWJnZH43LvvZzNZ2Lra4HbFSVJmwoK9XZTibxsu8Zcvf02u/WcFAmjO24nryi8
	Ytrj7jijznH1O4mfEhxF2PAKEt8sGx8KcAa+ZhcjBOApOP0EuDplNagMHvpwULzcohk/
	N3ZU5vHbnQran7UGLygWEyZBQPplaAB/OB67B64/rZZjiEjlKIixyDjw87W7LSVfbEYF
	o4oQql+ZbWczkEBxKPGjemXhS08BncRpsy4WldLt2ywSOeLby4/m3Pf7KwP8ZKH8TdtT
	meCA==
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:cc;
	bh=HWB/+zkBFfA0uVxhjkuTP6coi32O3YnxhPk+GJo4rq4=;
	b=Hi00l9Aipxtat4XXTdAUYrLfMd22HtsmWQPqRVc47IdXwi/CRA3pIN5jg517P3Yqu9
	TDWIBmInptFRAKWMMcZyg4NPcfnsUjgGDlE72ntL81ZgpIDdQ9F1bbDuNviAoTTXLU37
	diHTJ02iUQmqYUZUibulUMYSZOiUJ+57n8LKWoBqdgXiHvvYXYh44qItYDCgaxwyP9kq
	LcMxsEHo1j+aPQomsa1OHiZQLMypZrA2cGxtwS8AikMOrGNlBN+m1Jol1WXDWulnakMy
	42DK0z055tfgG9T98609acVE/LwoKTdSHcGnn6DJElmdQusac1zcrcZGA3ViEr6TO9Ol
	TBSw==
X-Gm-Message-State: AHYfb5iBqNF1D1uev/YWr9oLZXMcUFAGQ1pdg1w3TwPeuHZnnTBScqep
	W9JabhHGG5Df/1x/SnUP7l9viFwI7Q==
X-Received: by 10.55.94.2 with SMTP id s2mr24348792qkb.253.1503325596114; Mon,
	21 Aug 2017 07:26:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.63.2 with HTTP; Mon, 21 Aug 2017 07:26:35 -0700 (PDT)
In-Reply-To: <6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
	<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
	<6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Mon, 21 Aug 2017 10:26:35 -0400
Message-ID: <CACiOHGwdNb=R95mE=UJOynKBtOc43Cxbjff8uZ4qakLMNX=Lbw@mail.gmail.com>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114e640423652e05574444d9"
X-Mailman-Approved-At: Mon, 21 Aug 2017 14:32:07 +0000
Cc: Major Kusanagi <majorkusanagibtc@gmail.com>
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: Mon, 21 Aug 2017 14:26:37 -0000

--001a114e640423652e05574444d9
Content-Type: text/plain; charset="UTF-8"

A more forgiving option would be to have coins past a certain age evaporate
into mining rewards at some rate, rather than all at once. People might
find this approach easier to stomach as it avoids the "I waited 1 block to
many and all of my coins vanished" scenario.

Another approach would to demand that a certain minimum mining fee be
included that is calculated based on the age of an input like this idea:
https://www.reddit.com/r/Bitcoin/comments/35ilir/prioritizing_utxos_using_a_minimum_mining_fee/

This would result in the coins continuing to exist but not being
economically spendable, and therefore the UTXO information could be
archived.

On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
> > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
> >
> >     [...] 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.
> >
> >
> > Unless there is a logical contradiction in this phrasing, the proposed
> > solution does not improves scalability:
> >  - "Bitcoins lasting forever" implies "unscalable";
> >  - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> > forever";
> >  - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
> >
> > In practice, the only Bitcoin lost would be those whose owners forgot
> > about or has lost the keys, because everyone with a significant amount
> > of Bitcoins would always shift them around before it loses any luster (I
> > wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> > estimate the percentage of UTXO is actually lost/forgotten, but I have
> > the opinion it isn't worth the hassle.
> >
> > As a side note, your estimate talks about block size, which is
> > determines blockchain size, which can be "safely" pruned (if you are not
> > considering new nodes might want to join the network, in case the full
> > history is needed to be stored somewhere). But UTXO size, albeit related
> > to the full blockchain size, is the part that currently can not be
> > safely pruned, so I don't see the relevance of the analysis.
>
> I think if we wanted to burn lost/stale coins a better approach would be
> returning them to miner's as a fee - there will always be lost coins and
> miners will be able to get that additional revenue stream as the mining
> reward halves. I also don't think we need to worry about doing a gradual
> value loss neither, we should just put a limit on UTXO age in block
> count (actually I would round it up to 210k blocks as explained below...).
>
>
> So lets say for example we decide to keep 5 210k blocks "generations"
> (that's over 15 years), then on the first block of the 6th generation
> all UTXO's from the 1st generation are invalidated and returned into a
> "pool".
>
> Given these (values in satoshis):
>
> Pool "P" (invalided UTXO minus total value reclaimed since last halving)
> Leftover blocks "B" (210,000 minus blocks mined since last halving)
>
> Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
> miner's reward and tx fees.
>
> If the last block of a generation does not get the remainder of the pool
> (FLOOR(P/1) == P) it should get carried over.
>
>
> This would ensure we can clear old blocks after a few generations and
> that burnt/lost coins eventually get back in circulation. Also it would
> reduce the reliance of miners on actual TX fees.
>
>
> To avoid excessive miner reward initially, for the first few iterations
> the value of B could be increased (I haven't calculated the UTXO size of
> the first 210k blocks but it could be excessively high...) or the value
> each block can reclaim could be caped (so we would reclaim at an
> artificial capacity until the pool depletes...).
>
>
> Regards,
>
> --
> Thomas
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">A more forgiving option would be to have coins past a cert=
ain age evaporate into mining rewards at some rate, rather than all at once=
. People might find this approach easier to stomach as it avoids the &quot;=
I waited 1 block to many and all of my coins vanished&quot; scenario.<div><=
br></div><div>Another approach would to demand that a certain minimum minin=
g fee be included that is calculated based on the age of an input like this=
 idea: <a href=3D"https://www.reddit.com/r/Bitcoin/comments/35ilir/prioriti=
zing_utxos_using_a_minimum_mining_fee/">https://www.reddit.com/r/Bitcoin/co=
mments/35ilir/prioritizing_utxos_using_a_minimum_mining_fee/</a></div><div>=
<br></div><div>This would result in the coins continuing to exist but not b=
eing economically spendable, and therefore the UTXO information could be ar=
chived.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 21/07/17 03:59 P=
M, Lucas Clemente Vella via bitcoin-dev wrote:<br>
&gt; 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
</span>&gt; &lt;mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;&gt;:<br>
<span class=3D"">&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0[...] But the fact is that if we want to make bitco=
ins last forever,<br>
&gt;=C2=A0 =C2=A0 =C2=A0we have the accept unbounded UTXO growth, which is =
unscalable. So<br>
&gt;=C2=A0 =C2=A0 =C2=A0the only solution is to limit UTXO growth, meaning =
bitcoins cannot<br>
&gt;=C2=A0 =C2=A0 =C2=A0last forever. This proposed solution however does n=
ot prevent<br>
&gt;=C2=A0 =C2=A0 =C2=A0Bitcoin from lasting forever.<br>
&gt;<br>
&gt;<br>
&gt; Unless there is a logical contradiction in this phrasing, the proposed=
<br>
&gt; solution does not improves scalability:<br>
&gt;=C2=A0 - &quot;Bitcoins lasting forever&quot; implies &quot;unscalable&=
quot;;<br>
&gt;=C2=A0 - &quot;not prevent Bitcoin from lasting forever&quot; implies &=
quot;Bitcoins lasting<br>
&gt; forever&quot;;<br>
&gt;=C2=A0 - Thus: &quot;not prevent Bitcoin from lasting forever&quot; imp=
lies &quot;unscalable&quot;.<br>
&gt;<br>
&gt; In practice, the only Bitcoin lost would be those whose owners forgot<=
br>
&gt; about or has lost the keys, because everyone with a significant amount=
<br>
&gt; of Bitcoins would always shift them around before it loses any luster =
(I<br>
&gt; wouldn&#39;t bother to move my Bitcoins every 10 years). I don&#39;t k=
now how to<br>
&gt; estimate the percentage of UTXO is actually lost/forgotten, but I have=
<br>
&gt; the opinion it isn&#39;t worth the hassle.<br>
&gt;<br>
&gt; As a side note, your estimate talks about block size, which is<br>
&gt; determines blockchain size, which can be &quot;safely&quot; pruned (if=
 you are not<br>
&gt; considering new nodes might want to join the network, in case the full=
<br>
&gt; history is needed to be stored somewhere). But UTXO size, albeit relat=
ed<br>
&gt; to the full blockchain size, is the part that currently can not be<br>
&gt; safely pruned, so I don&#39;t see the relevance of the analysis.<br>
<br>
</span>I think if we wanted to burn lost/stale coins a better approach woul=
d be<br>
returning them to miner&#39;s as a fee - there will always be lost coins an=
d<br>
miners will be able to get that additional revenue stream as the mining<br>
reward halves. I also don&#39;t think we need to worry about doing a gradua=
l<br>
value loss neither, we should just put a limit on UTXO age in block<br>
count (actually I would round it up to 210k blocks as explained below...).<=
br>
<br>
<br>
So lets say for example we decide to keep 5 210k blocks &quot;generations&q=
uot;<br>
(that&#39;s over 15 years), then on the first block of the 6th generation<b=
r>
all UTXO&#39;s from the 1st generation are invalidated and returned into a<=
br>
&quot;pool&quot;.<br>
<br>
Given these (values in satoshis):<br>
<br>
Pool &quot;P&quot; (invalided UTXO minus total value reclaimed since last h=
alving)<br>
Leftover blocks &quot;B&quot; (210,000 minus blocks mined since last halvin=
g)<br>
<br>
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to<br>
miner&#39;s reward and tx fees.<br>
<br>
If the last block of a generation does not get the remainder of the pool<br=
>
(FLOOR(P/1) =3D=3D P) it should get carried over.<br>
<br>
<br>
This would ensure we can clear old blocks after a few generations and<br>
that burnt/lost coins eventually get back in circulation. Also it would<br>
reduce the reliance of miners on actual TX fees.<br>
<br>
<br>
To avoid excessive miner reward initially, for the first few iterations<br>
the value of B could be increased (I haven&#39;t calculated the UTXO size o=
f<br>
the first 210k blocks but it could be excessively high...) or the value<br>
each block can reclaim could be caped (so we would reclaim at an<br>
artificial capacity until the pool depletes...).<br>
<br>
<br>
Regards,<br>
<br>
--<br>
Thomas<br>
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br></div>

--001a114e640423652e05574444d9--