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

[Major Kusanagi <majorkusanagibtc@gmail.com>]

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

On Fri, Jul 21, 2017 at 12:54 PM, Jameson Lopp <jameson.lopp@gmail.com>
wrote:

> Sounds like demurrage to me, which has been implemented in other
> cryptocurrencies such as Freicoin - http://freico.in/
>

I don’t think it’s like demurrage in Freicoin at all. The purpose of the
proposal is to help Bitcoin scale, which is not the purpose of Freicoin’s
demurrage fee. Demurrage fee is not optional in Freicoin, and with this
proposal most users will likely never have to burn any coins at all given
how long it would take for bitcoins to lose their luster.



> 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.
>
> I don’t think most would find it untenable, because the proposal in
practice would not affect 99.9% of users because it is unlikely that coins
will ever get to the point where they start losing their luster.



> 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 believe with this proposal, finding a consensus for CONOP becomes a lot
less controversial. Because by putting a cap on the block chain size and
UTXO set, we know exactly how much disk space and RAM a node needs to run a
full node.



> 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.
>
> Sorry, let me clarify. I forgot to address the issue of how new nodes sync
the block chain. I mean to say that we should prune the old UTXOs along
with the old blocks. This would mean that we would have to create a
checkpoint every ~150 fifty years (base on my example) and node would drop
blocks older then those checkpoints.  This would mean new nodes would start
syncing from the checkpoint not the genesis block.



> - 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: 10269 bytes --]