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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
|
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 94C99728
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 17:26:59 +0000 (UTC)
X-Greylist: from auto-whitelisted 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 1A2B71F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 17:24:37 +0000 (UTC)
Received: (qmail 17382 invoked by uid 89); 22 Aug 2017 17:24:13 -0000
Received: by simscan 1.2.0 ppid: 17369, pid: 17376, t: 0.0124s
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;
22 Aug 2017 17:24:13 -0000
Received: (qmail 12705 invoked by uid 89); 22 Aug 2017 17:24:12 -0000
Received: by simscan 1.2.0 ppid: 12674, pid: 12677, t: 7.0201s
scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.97.8/m: spam: 3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=unavailable version=3.3.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; 22 Aug 2017 17:24:05 -0000
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Chris Riley <criley@gmail.com>
References: <CALKSEdq0CUKPY2u+WfAaWtg5nXYKCJzRnDbU2iMs8PQQSpPDGA@mail.gmail.com>
<CAL5BAw2GoQb3-R1Ybe581MbOQvx8wvT0bLoEQ29caNVJTFShmA@mail.gmail.com>
<CAJowKgJhN=Se=kqrFR_B4zJQGf3iBpM6hU+xeUN9eANsmVuwXQ@mail.gmail.com>
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
Message-ID: <4c39bee6-f419-2e36-62a8-d38171b15558@aei.ca>
Date: Tue, 22 Aug 2017 13:24:05 -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: <CAJowKgJhN=Se=kqrFR_B4zJQGf3iBpM6hU+xeUN9eANsmVuwXQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------41083E743324EA1092F15B2A"
X-Mailman-Approved-At: Tue, 22 Aug 2017 17:29:22 +0000
Cc: Matthew Beton <matthew.beton@gmail.com>
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: Tue, 22 Aug 2017 17:26:59 -0000
This is a multi-part message in MIME format.
--------------41083E743324EA1092F15B2A
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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
On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
> I agree, it is only a good idea in the event of a quantum computing
> threat to the security of Bitcoin. =20
>
> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> This seems to be drifting off into alt-coin discussion. The idea
> that we can change the rules and steal coins at a later date
> because they are "stale" or someone is "hoarding" is antithetical
> to one of the points of bitcoin in that you can no longer control
> your own money ("be your own bank") because someone can at a later
> date take your coins for some reason that is outside your control
> and solely based on some rationalization by a third party. Once
> the rule is established that there are valid reasons why someone
> should not have control of their own bitcoins, what other reasons
> will then be determined to be valid?
>
> I can imagine Hal Finney being revived (he was cryo-preserved at
> Alcor if you aren't aware) after 100 or 200 years expecting his
> coins to be there only to find out that his coins were deemed
> "stale" so were "reclaimed" (in the current doublespeak - e.g.
> stolen or confiscated). Or perhaps he locked some for his
> children and they are found to be "stale" before they are
> available. He said in March 2013, "I think they're safe enough"
> stored in a paper wallet. Perhaps any remaining coins are no
> longer "safe enough."
>
> Again, this seems (a) more about an alt-coin/bitcoin fork or (b)
> better in bitcoin-discuss at best vs bitcoin-dev. I've seen it
> discussed many times since 2010 and still do not agree with the
> rational that embracing allowing someone to steal someone else's
> coins for any reason is a useful change to bitcoin.
>
>
>
>
> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> 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 i=
t.
>
--------------41083E743324EA1092F15B2A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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)<br>
<br>
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.<br>
<br>
--<br>
Thomas<br>
<br>
<div class="moz-cite-prefix">On 22/08/17 10:29 AM, Erik Aronesty via
bitcoin-dev wrote:<br>
</div>
<blockquote
cite="mid:CAJowKgJhN=Se=kqrFR_B4zJQGf3iBpM6hU+xeUN9eANsmVuwXQ@mail.gmail.com"
type="cite">
<div dir="ltr">I agree, it is only a good idea in the event of a
quantum computing threat to the security of Bitcoin. <br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 22, 2017 at 9:45 AM, Chris
Riley via bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">This seems to be drifting off into alt-coin
discussion. The idea that we can change the rules and
steal coins at a later date because they are "stale" or
someone is "hoarding" is antithetical to one of the points
of bitcoin in that you can no longer control your own
money ("be your own bank") because someone can at a later
date take your coins for some reason that is outside your
control and solely based on some rationalization by a
third party. Once the rule is established that there are
valid reasons why someone should not have control of their
own bitcoins, what other reasons will then be determined
to be valid?
<div><br>
</div>
<div>I can imagine Hal Finney being revived (he was
cryo-preserved at Alcor if you aren't aware) after 100
or 200 years expecting his coins to be there only to
find out that his coins were deemed "stale" so were
"reclaimed" (in the current doublespeak - e.g. stolen or
confiscated). Or perhaps he locked some for his
children and they are found to be "stale" before they
are available. He said in March 2013, "I think they're
safe enough" stored in a paper wallet. Perhaps any
remaining coins are no longer "safe enough."<br>
<div><br>
</div>
<div>Again, this seems (a) more about an
alt-coin/bitcoin fork or (b) better in bitcoin-discuss
at best vs bitcoin-dev. I've seen it discussed many
times since 2010 and still do not agree with the
rational that embracing allowing someone to steal
someone else's coins for any reason is a useful change
to bitcoin.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Tue, Aug 22, 2017 at 4:19 AM,
Matthew Beton via bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5"><span>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:</span><br>
<br>
<span>B - the current block number</span><br>
<span>P - how many blocks behind current the coin
burning block is. (630000, 840000, or
otherwise.)</span><br>
<br>
<span>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.</span>
<br>
</div>
</div>
<span class=""></span></blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>
--------------41083E743324EA1092F15B2A--
|
