public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Moral Agent <ethan.scruples@gmail.com>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: Major Kusanagi <majorkusanagibtc@gmail.com>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Mon, 21 Aug 2017 10:26:35 -0400	[thread overview]
Message-ID: <CACiOHGwdNb=R95mE=UJOynKBtOc43Cxbjff8uZ4qakLMNX=Lbw@mail.gmail.com> (raw)
In-Reply-To: <6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca>

[-- Attachment #1: Type: text/plain, Size: 4404 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5815 bytes --]

  reply	other threads:[~2017-08-21 14:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 19:28 [bitcoin-dev] UTXO growth scaling solution proposal Major Kusanagi
2017-07-21 19:52 ` Jeremy
2017-07-21 19:54 ` Jameson Lopp
2017-07-22  6:43   ` Major Kusanagi
2017-07-21 19:59 ` Lucas Clemente Vella
2017-07-21 20:17   ` Moral Agent
2017-07-22  6:45   ` Major Kusanagi
2017-08-21 13:35   ` Thomas Guyot-Sionnest
2017-08-21 14:26     ` Moral Agent [this message]
2017-08-21 17:24       ` Erik Aronesty
2017-08-22  8:19 Matthew Beton
2017-08-22 13:45 ` Chris Riley
2017-08-22 14:04   ` Matthew Beton
2017-08-22 14:29   ` Erik Aronesty
2017-08-22 17:24     ` Thomas Guyot-Sionnest
2017-08-22 17:33       ` Matthew Beton
2017-08-22 18:55         ` Chris Riley
2017-08-22 20:06           ` Erik Aronesty
2017-08-22 20:20             ` Mark Friedenbach
2017-08-22 22:17 Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest
2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23  3:26   ` Mark Friedenbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACiOHGwdNb=R95mE=UJOynKBtOc43Cxbjff8uZ4qakLMNX=Lbw@mail.gmail.com' \
    --to=ethan.scruples@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dermoth@aei.ca \
    --cc=majorkusanagibtc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox