1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <dermoth@aei.ca>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DB5C1481
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 13:42:12 +0000 (UTC)
X-Greylist: delayed 00:06:41 by SQLgrey-1.7.6
Received: from mail001.aei.ca (mail001.aei.ca [206.123.6.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B77088
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 13:42:12 +0000 (UTC)
Received: (qmail 1286 invoked by uid 89); 21 Aug 2017 13:35:30 -0000
Received: by simscan 1.2.0 ppid: 1281, pid: 1284, t: 0.0055s
scanners: regex: 1.2.0 attach: 1.2.0
Received: from mail002.aei.ca (HELO mail002.contact.net) (206.123.6.132)
by mail001.aei.ca with (DHE-RSA-AES256-SHA encrypted) SMTP;
21 Aug 2017 13:35:30 -0000
Received: (qmail 28672 invoked by uid 89); 21 Aug 2017 13:35:29 -0000
Received: by simscan 1.2.0 ppid: 28600, pid: 28614, t: 6.9144s
scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28)
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=5.0 tests=ALL_TRUSTED,BAYES_00
autolearn=ham autolearn_force=no version=3.4.1
Received: from dsl-66-36-135-64.mtl.aei.ca (HELO ?192.168.67.200?)
(dermoth@66.36.135.64)
by mail.aei.ca with ESMTPA; 21 Aug 2017 13:35:22 -0000
To: Lucas Clemente Vella <lvella@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Major Kusanagi <majorkusanagibtc@gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca>
Date: Mon, 21 Aug 2017 09:35:22 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 21 Aug 2017 13:49:40 +0000
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Aug 2017 13:42:13 -0000
On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>
> [...] 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.
>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
> - "Bitcoins lasting forever" implies "unscalable";
> - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
> - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>
> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount
> of Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have
> the opinion it isn't worth the hassle.
>
> As a side note, your estimate talks about block size, which is
> determines blockchain size, which can be "safely" pruned (if you are not
> considering new nodes might want to join the network, in case the full
> history is needed to be stored somewhere). But UTXO size, albeit related
> to the full blockchain size, is the part that currently can not be
> safely pruned, so I don't see the relevance of the analysis.
I think if we wanted to burn lost/stale coins a better approach would be
returning them to miner's as a fee - there will always be lost coins and
miners will be able to get that additional revenue stream as the mining
reward halves. I also don't think we need to worry about doing a gradual
value loss neither, we should just put a limit on UTXO age in block
count (actually I would round it up to 210k blocks as explained below...).
So lets say for example we decide to keep 5 210k blocks "generations"
(that's over 15 years), then on the first block of the 6th generation
all UTXO's from the 1st generation are invalidated and returned into a
"pool".
Given these (values in satoshis):
Pool "P" (invalided UTXO minus total value reclaimed since last halving)
Leftover blocks "B" (210,000 minus blocks mined since last halving)
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
miner's reward and tx fees.
If the last block of a generation does not get the remainder of the pool
(FLOOR(P/1) == P) it should get carried over.
This would ensure we can clear old blocks after a few generations and
that burnt/lost coins eventually get back in circulation. Also it would
reduce the reliance of miners on actual TX fees.
To avoid excessive miner reward initially, for the first few iterations
the value of B could be increased (I haven't calculated the UTXO size of
the first 210k blocks but it could be excessively high...) or the value
each block can reclaim could be caped (so we would reclaim at an
artificial capacity until the pool depletes...).
Regards,
--
Thomas
|
