Re: [bitcoin-dev] UTXO growth scaling solution proposal

From: Jameson Lopp <jameson.lopp@gmail•com>
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:54:26 -0400	[thread overview]
Message-ID: <CADL_X_cbvWf0OqW0KChJDOXA=B-eedUZ98J7v9vTvZL1gHx8pQ@mail.gmail.com> (raw)
In-Reply-To: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>

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

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’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: 7558 bytes --]