From: Major Kusanagi <majorkusanagibtc@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] UTXO growth scaling solution proposal
Date: Fri, 21 Jul 2017 19:28:57 +0000 [thread overview]
Message-ID: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5446 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5725 bytes --]
next reply other threads:[~2017-07-21 19:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 19:28 Major Kusanagi [this message]
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
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=CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com \
--to=majorkusanagibtc@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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