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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E15908D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Aug 2017 03:26:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
[209.85.192.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2F653F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Aug 2017 03:26:23 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id c28so2193366pfe.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Aug 2017 20:26:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=GLpEc/z6vePOrJaAOnKLd1cE9ZBza0c6uZXAfjyPEHo=;
b=LXmvIUd31XGkmwBBtyx2EqN0Wp4OwklxQSV02C/ilOc8E5/KgveLHjAf05TlXZ7oBI
kHBfn9NsOyF2A4MU2NVn9u5LNBb08aTaGy+CUpKQWhWrFtAN9ZRjtSdUJMBLOwuxV+/0
vIhbz+/VPugjoynMEt46ZRm9ekUjX1cU6LDABIWXc1Cp+cebbN2hdzhalfJjFdEVTlaK
3NXLZENLjtThPFSfZ/s6WhIlM5D26pQiYMsKgv7KVPVpu2mdHL1ZUtzVrSHCnrSmvM27
R1Cuvtm6mFzPbxgeC1gU0UfbmGSkWDphBOLEE5QUitkidtbHxuoad0vcc0NU0oQF2wce
4OBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=GLpEc/z6vePOrJaAOnKLd1cE9ZBza0c6uZXAfjyPEHo=;
b=OnLtxEccpjdC+Xtv0hm9Inb1yRqX2b3yCAjqlSmlI0Q4KgjlKMfeFf23ClvvU7a4Pl
KVcdt2AUt/j7UU8bcLyhl2sGBLtVsMj7upO+ejZhZpsWRUZ1riDyp3+HP3ScLTglN398
tgx8DH365TR8IphXqyfaVWzXdoUt6vlaiFlIJcr6ZMBXu6A1Yf1CFz1F08M+Gkl+sMuL
EPQVbN0Kfymv3RPq0UPpmndemtG26orfEfLXYviDZ9lsPYzdBNDrEIpk5MAaYqJCrXto
PSV/c8c07mkI2ZuEUR5peXc+qBAxQx5nwqDcxVIi6aXUv6+BAODaw9fblyiZBMfQL3GU
fAeQ==
X-Gm-Message-State: AHYfb5jfWcnsA+xtZLBJlojU/kMskjb0r/XBWf+iRAwTkwN3tMjC0Xl9
kWwEt+lSIOY0t0zS
X-Received: by 10.99.117.12 with SMTP id q12mr1248523pgc.59.1503458783360;
Tue, 22 Aug 2017 20:26:23 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:69bc:9ed4:458d:cfa6?
([2601:646:8080:1291:69bc:9ed4:458d:cfa6])
by smtp.gmail.com with ESMTPSA id g14sm551705pfm.77.2017.08.22.20.26.20
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 22 Aug 2017 20:26:21 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <f440fb62-4837-b98d-15e5-fd871ce3869e@aei.ca>
Date: Tue, 22 Aug 2017 20:26:19 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <02ECA1E2-B113-4668-984A-70445052C8B9@friedenbach.org>
References: <CABerxhG6HTZF+J5f0R3cpLvMjFW06p7ar_JGX9Oidokz-PT4=g@mail.gmail.com>
<f440fb62-4837-b98d-15e5-fd871ce3869e@aei.ca>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailman-Approved-At: Wed, 23 Aug 2017 03:28:04 +0000
Cc: Rodney Morris <rodney.morris@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: Wed, 23 Aug 2017 03:26:24 -0000
--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Lock time transactions have been valid for over a year now I believe. In any=
case we can't scan the block chain for usage patterns in UTXOs because P2SH=
puts the script in the signature on spend.
> On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>=20
> I'm just getting the proposal out... if we decide to go forward (pretty hu=
ge "if" right now) whenever it kicks in after 15, 50 or 100 years should be d=
ecided as early as possible.
>=20
> Are CheckLockTimeVerify transactions accepted yet? I thought most special t=
ransactions were only accepted on Testnet... In any case we should be able t=
o scan the blockchain and look for any such transaction. And I hate to make t=
his more complex, but maybe re-issuing the tx from coinbase could be an opti=
on?
>=20
> --
> Thomas
>=20
>> On 22/08/17 06:58 PM, Rodney Morris via bitcoin-dev wrote:
>> Thomas et.al.
>>=20
>> So, in your minds, anyone who locked up coins using CLTV for their child t=
o receive on their 21st birthday, for the sake of argument, has effectively f=
orfeit those coins after the fact? You are going to force anyone who took c=
oins offline (cryptosteel, paper, doesn't matter) to bring those coins back o=
nline, with the inherent security risks?
>>=20
>> In my mind, the only sane way to even begin discussing an approach implem=
enting such a thing - where coins "expire" after X years - would be to give t=
he entire ecosystem X*N years warning, where N > 1.5. I'd also suggest X wo=
uld need to be closer to the life span of a human than zero. Mind you, I'd s=
uggest this "feature" would need to be coded and deployed as a future-hard-f=
ork X*N years ahead of time. A-la Satoshi's blog post regarding increasing b=
lock size limit, a good enough approximation would be to add a block height c=
heck to the code that approximates X*N years, based on 10 minute blocks. Th=
e transparency around such a change would need to be radical and absolute.
>>=20
>> I'd also suggest that, similar to CLTV, it only makes sense to discuss cr=
eating a "never expire" transaction output, if such a feature were being ser=
iously considered.
>>=20
>> If you think discussions around a block size increase were difficult, the=
n we'll need a new word to describe the challenges and vitriol that would ar=
ise in arguments that will follow this discussion should it be seriously pro=
posed, IMHO.
>>=20
>> 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/br=
eaking of ECC poses a real risk to the stability of Bitcoin - the possible r=
elease of Satoshi's stash being the most obvious example - and what to do ab=
out that will require serious consideration when the time comes. Even if th=
e end result is the same - that coins older than "X" will be invalidated - e=
verything else important about the scenarios are different as far as I can s=
ee.
>>=20
>> Rodney
>>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 7bit
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Lock time transactions have been valid for over a year now I believe. In any case we can't scan the block chain for usage patterns in UTXOs because P2SH puts the script in the signature on spend.<br></div><div><br>On Aug 22, 2017, at 4:29 PM, Thomas Guyot-Sionnest via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
I'm just getting the proposal out... if we decide to go forward
(pretty huge "if" right now) whenever it kicks in after 15, 50 or
100 years should be decided as early as possible.<br>
<br>
Are CheckLockTimeVerify transactions accepted yet? I thought most
special transactions were only accepted on Testnet... In any case we
should be able to scan the blockchain and look for any such
transaction. And I hate to make this more complex, but maybe
re-issuing the tx from coinbase could be an option?<br>
<br>
--<br>
Thomas<br>
<br>
<div class="moz-cite-prefix">On 22/08/17 06:58 PM, Rodney Morris via
bitcoin-dev wrote:<br>
</div>
<blockquote cite="mid:CABerxhG6HTZF+J5f0R3cpLvMjFW06p7ar_JGX9Oidokz-PT4=g@mail.gmail.com" type="cite">
<div dir="ltr">
<div>Thomas <a moz-do-not-send="true" href="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, 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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</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 vitriol 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. 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.</div>
<div><br>
</div>
<div>Rodney</div>
<br>
</div>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></html>
--Apple-Mail-70C4233B-5D3D-45BF-B08D-F385931D727B--
|
