public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22 22:17 Daniele Pinna
  2017-08-22 23:27 ` Thomas Guyot-Sionnest
  0 siblings, 1 reply; 24+ messages in thread
From: Daniele Pinna @ 2017-08-22 22:17 UTC (permalink / raw)
  To: Bitcoin Dev

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

Also.... how is this not a tax on coin holders? By forcing people to move
coins around you would be chipping away at their wealth in the form of
extorted TX fees.

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22 22:58 Rodney Morris
  2017-08-22 23:29 ` Thomas Guyot-Sionnest
  0 siblings, 1 reply; 24+ messages in thread
From: Rodney Morris @ 2017-08-22 22:58 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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

Thomas et.al.

So, in your minds, anyone who locked up coins using CLTV for their child to
receive on their 21st birthday, for the sake of argument, has effectively
forfeit those coins after the fact?  You are going to force anyone who took
coins offline (cryptosteel, paper, doesn't matter) to bring those coins
back online, with the inherent security risks?

In my mind, the only sane way to even begin discussing an approach
implementing such a thing - where coins "expire" after X years - would be
to give the entire ecosystem X*N years warning, where N > 1.5.  I'd also
suggest X would need to be closer to the life span of a human than zero.
Mind you, I'd suggest this "feature" would need to be coded and deployed as
a future-hard-fork X*N years ahead of time.  A-la Satoshi's blog post
regarding increasing block size limit, a good enough approximation would be
to add a block height check to the code that approximates X*N years, based
on 10 minute blocks.  The transparency around such a change would need to
be radical and absolute.

I'd also suggest that, similar to CLTV, it only makes sense to discuss
creating a "never expire" transaction output, if such a feature were being
seriously considered.

If you think discussions around a block size increase were difficult, then
we'll need a new word to describe the challenges and vitriol that would
arise in arguments that will follow this discussion should it be seriously
proposed, IMHO.

I also don't think it's reasonable to conflate the discussion herein with
discussion about what to do when ECC or SHA256 is broken.  The
weakening/breaking of ECC poses a real risk to the stability of Bitcoin -
the possible release of Satoshi's stash being the most obvious example -
and what to do about that will require serious consideration when the time
comes.  Even if the end result is the same - that coins older than "X" will
be invalidated - everything else important about the scenarios are
different as far as I can see.

Rodney



>
>
> Date: Tue, 22 Aug 2017 13:24:05 -0400
> From: Thomas Guyot-Sionnest <dermoth@aei•ca>
> To: Erik Aronesty <erik@q32•com>,       Bitcoin Protocol Discussion
>         <bitcoin-dev@lists•linuxfoundation.org>,        Chris Riley
>         <criley@gmail•com>
> Cc: Matthew Beton <matthew.beton@gmail•com>
> Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
> Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15558@aei•ca>
> Content-Type: text/plain; charset="windows-1252"
>
> In any case when Hal Finney do not wake up from his 200years
> cryo-preservation (because unfortunately for him 200 years earlier they
> did not know how to preserve a body well enough to resurrect it) he
> would find that advance in computer technology made it trivial for
> anyone to steal his coins using the long-obsolete secp256k1 ec curve
> (which was done long before, as soon as it became profitable to crack
> down the huge stash of coins stale in the early blocks)
>
> I just don't get that argument that you can't be "your own bank". The
> only requirement coming from this would be to move your coins about once
> every 10 years or so, which you should be able to do if you have your
> private keys (you should!). You say it may be something to consider when
> computer breakthroughs makes old outputs vulnerable, but I say it's not
> "if" but "when" it happens, and by telling firsthand people that their
> coins requires moving every once in a long while you ensure they won't
> do stupid things or come back 50 years from now and complain their
> addresses have been scavenged.
>
> --
> Thomas
>
>
>

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-08-22  8:19 Matthew Beton
  2017-08-22 13:45 ` Chris Riley
  0 siblings, 1 reply; 24+ messages in thread
From: Matthew Beton @ 2017-08-22  8:19 UTC (permalink / raw)
  To: bitcoin-dev

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

Okay so I quite like this idea. If we start removing at height 630000 or
840000 (gives us 4-8 years to develop this solution), it stays nice and
neat with the halving interval. We can look at this like so:

B - the current block number
P - how many blocks behind current the coin burning block is. (630000,
840000, or otherwise.)

Every time we mine a new block, we go to block (B-P), and check for stale
coins. These coins get burnt up and pooled into block B's miner fees. This
keeps the mining rewards up in the long term, people are less likely to
stop mining due to too low fees. It also encourages people to keep moving
their money around the enconomy instead of just hording and leaving it.

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* [bitcoin-dev] UTXO growth scaling solution proposal
@ 2017-07-21 19:28 Major Kusanagi
  2017-07-21 19:52 ` Jeremy
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Major Kusanagi @ 2017-07-21 19:28 UTC (permalink / raw)
  To: bitcoin-dev

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-08-23  3:26 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-22 22:17 [bitcoin-dev] UTXO growth scaling solution proposal Daniele Pinna
2017-08-22 23:27 ` Thomas Guyot-Sionnest
  -- strict thread matches above, loose matches on Subject: below --
2017-08-22 22:58 Rodney Morris
2017-08-22 23:29 ` Thomas Guyot-Sionnest
2017-08-23  3:26   ` Mark Friedenbach
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-07-21 19:28 Major Kusanagi
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox