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
|
Return-Path: <rodney.morris@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 60CBB904
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 22:58:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D00016A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 22:58:57 +0000 (UTC)
Received: by mail-wm0-f43.google.com with SMTP id l19so3743795wmi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 15:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=EifJ+Nxtzd5B5kvVKMkfMg696Rge+T16CTMwMGNkgBY=;
b=MEPps1wc5J7Q/Tm7ePfE1qc0e7QmaPShYhFjgiMd23SipSS9krq//IboFnoWxXg7tq
aGitZUAaZ07f/t6Jf1zGWpL0EWHEGvbfMfQMhD8mlfcydlS8vERb+PaKjyr8w0ImJNdo
Mb72G8VZPWKv1HaWvaUNVHgR1dWgRmLrtb+DstTHz3nIAebqYWLzP1zdrGjo6JU8xp9X
RA+eN3mQro0m9CVQjELzQBgJpcqgxaE8uCxodHhl2WjFM+iW6VoRQL6AgiJenFBnHIir
etZXS6UbeoBtuQPn/qN5MxH7+BTriUPnMqmLjWI0G1V9tKlGSn6TjBxiLy3aMxagCmW0
0yXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=EifJ+Nxtzd5B5kvVKMkfMg696Rge+T16CTMwMGNkgBY=;
b=Qt+un3Y8C5y4goyeERJSUUzEQc5b9vD5cyX4pMGT4pzkXNp33VUPTDB2M9Sno8e56V
9UlAjKW2zjBqbeeFvVksjZjFjVAcuqRpmn9eWAqwuCryDIsoZf2ay8VX4U57hABGlkW5
tZ8Aq1qVdKUaYtS9JeCXnfIxKqzeP8GdoDdnPsqVPfJhwAjJcd2bXYU7z5cBCM40/uC1
W/8DqLKLPkUolNU8wwhb1BnljE68seHZSeslUzTwOxooSqzj9t1gJ7nLLCa6hW25yI/h
iaM+Rwt3uexVN/+F/FjMVY/ldVkb+N1SnoYJkqim7onImDNpLMCnad/kf3qyluP7Wsh7
56mg==
X-Gm-Message-State: AHYfb5iDUSO0Ap9NvV/lNL4kKLb6Zmthsegz9UXujvQocNkaCeP657rN
+NBwLwyig5WgH5vWf8yG4cAcIvEk0C5Y7d0=
X-Received: by 10.80.149.145 with SMTP id w17mr1370312eda.82.1503442735396;
Tue, 22 Aug 2017 15:58:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.143.68 with HTTP; Tue, 22 Aug 2017 15:58:54 -0700 (PDT)
From: Rodney Morris <rodney.morris@gmail.com>
Date: Wed, 23 Aug 2017 08:58:54 +1000
Message-ID: <CABerxhG6HTZF+J5f0R3cpLvMjFW06p7ar_JGX9Oidokz-PT4=g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c2c7c2efed205575f8ae2"
X-Mailman-Approved-At: Tue, 22 Aug 2017 23:06:00 +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: Tue, 22 Aug 2017 22:58:57 -0000
--f403045c2c7c2efed205575f8ae2
Content-Type: text/plain; charset="UTF-8"
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
>
>
>
--f403045c2c7c2efed205575f8ae2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thomas <a href=3D"http://et.al">et.al</a>.</div><div>=
<br></div><div>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, h=
as effectively forfeit those coins after the fact?=C2=A0 You are going to f=
orce anyone who took coins offline (cryptosteel, paper, doesn't matter)=
to bring those coins back online, with the inherent security risks?</div><=
div><br></div><div>In my mind, the only sane way to even begin discussing a=
n 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.=C2=A0 I'd also suggest X would need to be closer to the life=
span of a human than zero.=C2=A0 Mind you, I'd suggest this "feat=
ure" would need to be coded and deployed as a future-hard-fork X*N yea=
rs ahead of time.=C2=A0 A-la Satoshi's blog post regarding increasing b=
lock 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.=
=C2=A0 The transparency around such a change would need to be radical and a=
bsolute.</div><div><br></div><div>I'd also suggest that, similar to CLT=
V, it only makes sense to discuss creating a "never expire" trans=
action output, if such a feature were being seriously considered.</div><div=
><br></div><div>If you think discussions around a block size increase were =
difficult, then we'll need a new word to describe the challenges and vi=
triol that would arise in arguments that will follow this discussion should=
it be seriously proposed, IMHO.</div><div><br></div><div>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.=C2=A0 The weakening/breakin=
g of ECC poses a real risk to the stability of Bitcoin - the possible relea=
se of Satoshi's stash being the most obvious example - and what to do a=
bout that will require serious consideration when the time comes.=C2=A0 Eve=
n if the end result is the same - that coins older than "X" will =
be invalidated - everything else important about the scenarios are differen=
t as far as I can see.</div><div><br></div><div>Rodney</div><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br>
<br>
<br>Date: Tue, 22 Aug 2017 13:24:05 -0400<br>
From: Thomas Guyot-Sionnest <<a href=3D"mailto:dermoth@aei.ca">dermoth@a=
ei.ca</a>><br>
To: Erik Aronesty <<a href=3D"mailto:erik@q32.com">erik@q32.com</a>>,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>,=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Chris Riley<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:criley@gmail.com">criley@=
gmail.com</a>><br>
Cc: Matthew Beton <<a href=3D"mailto:matthew.beton@gmail.com">matthew.be=
ton@gmail.com</a>><br>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal<br>
Message-ID: <<a href=3D"mailto:4c39bee6-f419-2e36-62a8-d38171b15558@aei.=
ca">4c39bee6-f419-2e36-62a8-<wbr>d38171b15558@aei.ca</a>><br>
Content-Type: text/plain; charset=3D"windows-1252"<br>
<br>
In any case when Hal Finney do not wake up from his 200years<br>
cryo-preservation (because unfortunately for him 200 years earlier they<br>
did not know how to preserve a body well enough to resurrect it) he<br>
would find that advance in computer technology made it trivial for<br>
anyone to steal his coins using the long-obsolete secp256k1 ec curve<br>
(which was done long before, as soon as it became profitable to crack<br>
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 ban=
k". The<br>
only requirement coming from this would be to move your coins about once<br=
>
every 10 years or so, which you should be able to do if you have your<br>
private keys (you should!). You say it may be something to consider when<br=
>
computer breakthroughs makes old outputs vulnerable, but I say it's not=
<br>
"if" but "when" it happens, and by telling firsthand pe=
ople that their<br>
coins requires moving every once in a long while you ensure they won't<=
br>
do stupid things or come back 50 years from now and complain their<br>
addresses have been scavenged.<br>
<br>
--<br>
Thomas<br>
<br><br>
</blockquote></div><br></div></div>
--f403045c2c7c2efed205575f8ae2--
|
