public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy <jlrubin@mit•edu>
To: Major Kusanagi <majorkusanagibtc@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Fri, 21 Jul 2017 15:52:45 -0400	[thread overview]
Message-ID: <CAD5xwhiYfGcH6Bt2ESFAoR7pt9-vC1zXio3pk1X-h60m_QMqZQ@mail.gmail.com> (raw)
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>

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

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’m new to the mailing list and have not been in the Bitcoin
> space as long as some have been, so I don’t know if anyone has thought 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 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.
>
> 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 never
> be larger then the set number of blocks and the size of the block chain is
> capped.
>
> But what this means for users is that bitcoins that have not been spent
> for a long time are “lost” forever. This proposed solution 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 moment
> and the next moment they are not. The experience that they get is that all
> of a sudden their old bitcoins are gone forever.
>
> The solution can be improved by adding this new mechanism to Bitcoin, that
> I will call luster. UTXO’s that are less then X blocks old has not lost any
> luster and have a luster value of 1. As UTXO’s get older, the luster value
> will continuously decrease until the UTXO’s become Z blocks old (where Z >
> X), and has lost all it’s luster and have a luster value of 0. UTXO’s that
> are in between X and Z blocks old have a luster value between 0 and 1. The
> 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 block.
> 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 burn
> 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 economy
> will never lose it’s 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. 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 its
> 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 has
> 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 with
> this propose scaling solution, coins can be stilled inherited, but it would
> 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 150
> years of history seems like one reasonable option.
>
> Then the question of how large blocks should be is simply a matter of what
> is the disk size requirement for a full node. For simplicity, assuming that
> a block is created every 10 minute, the blockchain size in terabyte can be
> express as the following.
> blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB
>
> Example values:
> blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB
> blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB
>
> So if we don’t want the block chain to be bigger then 8 TB, then we should
> have a block size of 1 MB. If we don’t 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 block
> 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 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 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2017-07-21 19:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 19:28 Major Kusanagi
2017-07-21 19:52 ` Jeremy [this message]
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
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=CAD5xwhiYfGcH6Bt2ESFAoR7pt9-vC1zXio3pk1X-h60m_QMqZQ@mail.gmail.com \
    --to=jlrubin@mit$(echo .)edu \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=majorkusanagibtc@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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