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

[Jeremy <jlrubin@mit.edu>]

[-- 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 --]