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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <btcdrak@gmail.com>) id 1YsFtP-0007D0-Ch
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 19:31:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.53 as permitted sender)
client-ip=209.85.216.53; envelope-from=btcdrak@gmail.com;
helo=mail-vn0-f53.google.com;
Received: from mail-vn0-f53.google.com ([209.85.216.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsFtN-0004DS-RQ
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 19:31:03 +0000
Received: by vnbf190 with SMTP id f190so1371561vnb.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 May 2015 12:30:56 -0700 (PDT)
X-Received: by 10.52.26.132 with SMTP id l4mr12440932vdg.72.1431459056327;
Tue, 12 May 2015 12:30:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.63.5 with HTTP; Tue, 12 May 2015 12:30:35 -0700 (PDT)
In-Reply-To: <CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com>
References: <20150504050715.GA18856@savin.petertodd.org>
<CADJgMzs3D=6pNOQhU3ubi6=C8javRtwL0VuGFWvU+6SiuB0YWg@mail.gmail.com>
<20150509091201.GA15088@savin.petertodd.org>
<CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Tue, 12 May 2015 20:30:35 +0100
Message-ID: <CADJgMzv1NdoXKDScQ1+OycijzME=W2YSut3GMF=EEuKQf6VeUg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=20cf307c9fb09021dd0515e78849
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HK_RANDOM_FROM From username looks random
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.6 HK_RANDOM_ENVFROM Envelope sender username looks random
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(btcdrak[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YsFtN-0004DS-RQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 19:31:03 -0000
--20cf307c9fb09021dd0515e78849
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Gavin and @NicolasDorier have a point: If there isn't actually scarcity of
NOPs because OP_NOP10 could become <type> OP_EX (if we run out), it makes
sense to chose the original unparameterised CLTV version #6124 which also
has been better tested. It's cleaner, more readable and results in a
slightly smaller script which has also got to be a plus.
On Tue, May 12, 2015 at 8:16 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> This saves us ocodes for later but it's uglier and produces slightly
> bigger scripts.
> If we're convinced it's worth it, seems like the right way to do it,
> and certainly cltv and rclv/op_maturity are related.
> But let's not forget that we can always use this same trick with the
> last opcode to get 2^64 brand new opcodes.
> So I'm not convinced at all on whether we want #5496 or #6124.
> But it would be nice to decide and stop blocking this.
>
> On Sat, May 9, 2015 at 11:12 AM, Peter Todd <pete@petertodd.org> wrote:
> > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
> >> > That said, if people have strong feelings about this, I would be
> willing
> >> > to make OP_CLTV work as follows:
> >> >
> >> > <nLockTime> 1 OP_CLTV
> >> >
> >> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> >> > future relative CLTV could then be a future soft-fork implemented as
> >> > follows:
> >> >
> >> > <relative nLockTime> 2 OP_CLTV
> >> >
> >> > On the bad side it'd be two or three days of work to rewrite all the
> >> > existing tests and example code and update the BIP, and (slightly)
> gets
> >> > us away from the well-tested existing implementation. It also may
> >> > complicate the codebase compared to sticking with just doing a Scrip=
t
> >> > v2.0, with the additional execution environment data required for v2=
.0
> >> > scripts cleanly separated out. But all in all, the above isn't too b=
ig
> >> > of a deal.
> >>
> >>
> >> Adding a parameter to OP_CLTV makes it much more flexible and is the
> most
> >> economic use of precious NOPs.
> >> The extra time required is ok and it would be good to make this change
> to
> >> the PR in time for the feature freeze.
> >
> > Done!
> >
> > https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8
> >
> >
> -------------------------------------------------------------------------=
-----
> > One dashboard for servers and applications across Physical-Virtual-Clou=
d
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insight=
s
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
--20cf307c9fb09021dd0515e78849
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Gavin and @NicolasDorier have a point: If there isn't =
actually scarcity of NOPs because OP_NOP10 could become <type> OP_EX =
(if we run out), it makes sense to chose the original unparameterised CLTV =
version #6124 which also has been better tested. It's cleaner, more rea=
dable and results in a slightly smaller script which has also got to be a p=
lus.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,=
May 12, 2015 at 8:16 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D=
"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">This saves us ocodes for later bu=
t it's uglier and produces slightly<br>
bigger scripts.<br>
If we're convinced it's worth it, seems like the right way to do it=
,<br>
and certainly cltv and rclv/op_maturity are related.<br>
But let's not forget that we can always use this same trick with the<br=
>
last opcode to get 2^64 brand new opcodes.<br>
So I'm not convinced at all on whether we want=C2=A0 #5496 or #6124.<br=
>
But it would be nice to decide and stop blocking=C2=A0 this.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Sat, May 9, 2015 at 11:12 AM, Peter Todd <<a href=3D"mailto:pete@pete=
rtodd.org">pete@petertodd.org</a>> wrote:<br>
> On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:<br>
>> > That said, if people have strong feelings about this, I would=
be willing<br>
>> > to make OP_CLTV work as follows:<br>
>> ><br>
>> >=C2=A0 =C2=A0 =C2=A0<nLockTime> 1 OP_CLTV<br>
>> ><br>
>> > Where the 1 selects absolute mode, and all others act as OP_N=
OP's. A<br>
>> > future relative CLTV could then be a future soft-fork impleme=
nted as<br>
>> > follows:<br>
>> ><br>
>> >=C2=A0 =C2=A0 =C2=A0<relative nLockTime> 2 OP_CLTV<br>
>> ><br>
>> > On the bad side it'd be two or three days of work to rewr=
ite all the<br>
>> > existing tests and example code and update the BIP, and (slig=
htly) gets<br>
>> > us away from the well-tested existing implementation. It also=
may<br>
>> > complicate the codebase compared to sticking with just doing =
a Script<br>
>> > v2.0, with the additional execution environment data required=
for v2.0<br>
>> > scripts cleanly separated out. But all in all, the above isn&=
#39;t too big<br>
>> > of a deal.<br>
>><br>
>><br>
>> Adding a parameter to OP_CLTV makes it much more flexible and is t=
he most<br>
>> economic use of precious NOPs.<br>
>> The extra time required is ok and it would be good to make this ch=
ange to<br>
>> the PR in time for the feature freeze.<br>
><br>
> Done!<br>
><br>
> <a href=3D"https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-1=
00454263" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/5496#is=
suecomment-100454263</a><br>
><br>
> --<br>
> 'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank=
">petertodd.org</a><br>
> 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8<br>
><br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">> ------------------=
------------------------------------------------------------<br>
> One dashboard for servers and applications across Physical-Virtual-Clo=
ud<br>
> Widest out-of-the-box monitoring support with 50+ applications<br>
> Performance metrics, stats and reports that give you Actionable Insigh=
ts<br>
> Deep dive visibility with transaction tracing using APM Insight.<br>
> <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" ta=
rget=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a>=
<br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
><br>
</div></div></blockquote></div><br></div>
--20cf307c9fb09021dd0515e78849--
|
