Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1EA75A7C for ; 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 ; Mon, 21 Aug 2017 14:26:36 +0000 (UTC) Received: by mail-qk0-f171.google.com with SMTP id u139so83273544qka.1 for ; 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: <6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca> From: Moral Agent Date: Mon, 21 Aug 2017 10:26:35 -0400 Message-ID: To: Thomas Guyot-Sionnest , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114e640423652e05574444d9" X-Mailman-Approved-At: Mon, 21 Aug 2017 14:32:07 +0000 Cc: Major Kusanagi 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > > >: > > > > [...] 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
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 "= I waited 1 block to many and all of my coins vanished" scenario.
<= br>
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: https://www.reddit.com/r/Bitcoin/co= mments/35ilir/prioritizing_utxos_using_a_minimum_mining_fee/
=
This would result in the coins continuing to exist but not b= eing economically spendable, and therefore the UTXO information could be ar= chived.

On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
On 21/07/17 03:59 P= M, Lucas Clemente Vella via bitcoin-dev wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>
>=C2=A0 =C2=A0 =C2=A0[...] But the fact is that if we want to make bitco= ins last forever,
>=C2=A0 =C2=A0 =C2=A0we have the accept unbounded UTXO growth, which is = unscalable. So
>=C2=A0 =C2=A0 =C2=A0the only solution is to limit UTXO growth, meaning = bitcoins cannot
>=C2=A0 =C2=A0 =C2=A0last forever. This proposed solution however does n= ot prevent
>=C2=A0 =C2=A0 =C2=A0Bitcoin from lasting forever.
>
>
> Unless there is a logical contradiction in this phrasing, the proposed=
> solution does not improves scalability:
>=C2=A0 - "Bitcoins lasting forever" implies "unscalable&= quot;;
>=C2=A0 - "not prevent Bitcoin from lasting forever" implies &= quot;Bitcoins lasting
> forever";
>=C2=A0 - Thus: "not prevent Bitcoin from lasting forever" imp= lies "unscalable".
>
> In practice, the only Bitcoin lost would be those whose owners forgot<= br> > 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 k= now 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 relat= ed
> 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 woul= d be
returning them to miner's as a fee - there will always be lost coins an= d
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 gradua= l
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...).<= br>

So lets say for example we decide to keep 5 210k blocks "generations&q= uot;
(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<= br> "pool".

Given these (values in satoshis):

Pool "P" (invalided UTXO minus total value reclaimed since last h= alving)
Leftover blocks "B" (210,000 minus blocks mined since last halvin= g)

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) =3D=3D 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 o= f
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--