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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BF21E2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Nov 2015 21:32:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
[209.85.220.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44B0312D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Nov 2015 21:32:56 +0000 (UTC)
Received: by padhx2 with SMTP id hx2so94867810pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Nov 2015 13:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:cc:message-id;
bh=ts5SN9PXHfz+Ihc4mVADzCvmhhwfTMXghhUcfR7Dc5g=;
b=nIqBaFYslwYWrtOUAjGX+hwUp7OBPSfw+aaKY5HKkr867U3eZqNvcfoKMeBl3fKkTV
Q3ywfFPz7iNMgz6xR5nHkVf9LdGBEp0FrBVMmWY3EHb6lA6ClYK7MipJx304I44eBpDM
dx3LL+307gvsgIBxlm59/65hccc46Osa9h1lGKW9FLl+11q8VF7LR9wzbsTKsKwl0vxt
eGtm9htJga0W8a4W+HLpveCWDEmte0wg/ESkdhFOcFOlNDjB2aeLe0tdAjMIlBy+6zeV
O81ecuva4F/xjWb+9LPB41eXSBYWV7RdaiziDOyTOOOC2lVZDkM1JL9Sa+0k8pvPVBPK
WWTg==
X-Received: by 10.98.43.18 with SMTP id r18mr42986763pfr.2.1448573576014;
Thu, 26 Nov 2015 13:32:56 -0800 (PST)
Received: from [192.168.1.100] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
b15sm29446199pfj.7.2015.11.26.13.32.54
(version=TLSv1/SSLv3 cipher=OTHER);
Thu, 26 Nov 2015 13:32:55 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum>
References: <em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----ANBYS1DAGU3RJGLC2VGJJZZ09H7MBG"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Thu, 26 Nov 2015 13:32:58 -0800
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@jtimon.cc>,
Btc Drak <btcdrak@gmail.com>
Message-ID: <523E7E80-A958-4333-96FB-1E0D36BB128F@gmail.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 26 Nov 2015 21:32:56 -0000
------ANBYS1DAGU3RJGLC2VGJJZZ09H7MBG
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK <condition > VERIFY.
Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.
However, this name is ridiculously long, so at least some part will require abbreviation.
In typical script example usage, most sensible seems to be to abbreviate both CLTV and CRLTV.
- Eric
On November 24, 2015 5:14:55 PM PST, Eric Lombrozo <elombrozo@gmail.com> wrote:
From a system developer standpoint, CHECKMATURITYVERIFY ties together
>the semantics of this opcode with another existing feature in the
>system
>(coinbase maturity).
>
>HOWEVER...
>
>from an application developer standpoint, I think the concept of a
>timelock is more relevant. Maturity is a concept that was introduced
>for
>the sake of reducing the disruptive impact of reorgs. Miners would
>prefer to be able to spend the coins immediately, but instead they are
>forced to wait due to inherent limitations of the system. Timelocks, on
>
>the other hand, are typically used to control when funds can be moved.
>In these use cases, one or more of the parties involved explicitly want
>
>there to be a delay even if there were an idealized situation in which
>consensus is always reached instantaneously and there were never any
>reorgs.
>
>Moreover, since we already have CLTV, adding RCLTV or some variant
>thereof makes the relationship between the two more explicit.
>
>So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.
>
>As for whether to explicitly use CHECK_..._VERIFY, consider that with
>segregated witness it will be possible to add opcodes that can push
>values onto the stack (rather than just hard failing or NOP), so
>there's
>something to be said for naming consistency.
>
>- Eric
>
>
>
>------ Original Message ------
>From: "Jorge Timón" <bitcoin-dev@lists.linuxfoundation.org>
>To: "Btc Drak" <btcdrak@gmail.com>
>Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>
>Sent: 11/24/2015 4:31:55 AM
>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY
>(BIP112)
>
>>I agree, I believe the first name that an op with equivalent
>>functionality had was simply op_maturity.
>>At least I remember we discussed such an opcode when discussing pegged
>
>>sidechains' design.
>>
>>I kind of dislike the check_x_verify naming pattern. We want all new
>>operands to return if whatever they're checking/verifying fails, fine.
>
>>Do we have to repeat this redundant naming pattern forever due to that
>
>>discovery?
>>I hope not, but if that's the case my vote is for CMV.
>>As said before, I believe the documentation and code comments can
>>become much more clear with this change.
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------ANBYS1DAGU3RJGLC2VGJJZZ09H7MBG
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head><style id="eMClientCss">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weight: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}
.plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;}
</style><style></style></head><body scroll="auto" class="class">After a little more though (and some comments from aj), I realize that the opcode naming convention is actually CHECK <condition > VERIFY.<br>
<br>
Therefore, the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY.<br>
<br>
However, this name is ridiculously long, so at least some part will require abbreviation.<br>
<br>
In typical script example usage, most sensible seems to be to abbreviate both CLTV and CRLTV.<br>
<br>
- Eric<br><br><div class="gmail_quote">On November 24, 2015 5:14:55 PM PST, Eric Lombrozo <elombrozo@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>From a system developer standpoint, CHECKMATURITYVERIFY ties together the semantics of this opcode with another existing feature in the system (coinbase maturity).</div>
<div> </div>
<div>HOWEVER...</div>
<div> </div>
<div>from an application developer standpoint, I think the concept of a timelock is more relevant. Maturity is a concept that was introduced for the sake of reducing the disruptive impact of reorgs. Miners would prefer to be able to spend the coins immediately, but instead they are forced to wait due to inherent limitations of the system. Timelocks, on the other hand, are typically used to control when funds can be moved. In these use cases, one or more of the parties involved explicitly want there to be a delay even if there were an idealized situation in which consensus is always reached instantaneously and there were never any reorgs.</div>
<div> </div>
<div>Moreover, since we already have CLTV, adding RCLTV or some variant thereof makes the relationship between the two more explicit.</div>
<div> </div>
<div>So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.</div>
<div> </div>
<div>As for whether to explicitly use CHECK_..._VERIFY, consider that with segregated witness it will be possible to add opcodes that can push values onto the stack (rather than just hard failing or NOP), so there's something to be said for naming consistency.</div>
<div> </div>
<div>- Eric</div>
<div> </div>
<div> </div>
<div> </div>
<div>------ Original Message ------</div>
<div>From: "Jorge Timón" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>></div>
<div>To: "Btc Drak" <<a href="mailto:btcdrak@gmail.com">btcdrak@gmail.com</a>></div>
<div>Cc: "Bitcoin Dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>></div>
<div>Sent: 11/24/2015 4:31:55 AM</div>
<div>Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)</div>
<div> </div>
<div id="xe40f4e1a28394eee96200b907d68005b">
<blockquote class="cite2" cite="CABm2gDqoq4pkXLS=4rKGOLGU0_0mq1_yMOHmLw73m=apiMRMpg@mail.gmail.com" type="cite">
<p dir="ltr">I agree, I believe the first name that an op with equivalent functionality had was simply op_maturity.<br />At least I remember we discussed such an opcode when discussing pegged sidechains' design.</p>
<p dir="ltr">I kind of dislike the check_x_verify naming pattern. We want all new operands to return if whatever they're checking/verifying fails, fine. Do we have to repeat this redundant naming pattern forever due to that discovery?<br />I hope not, but if that's the case my vote is for CMV.<br />As said before, I believe the documentation and code comments can become much more clear with this change.</p></blockquote></div></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------ANBYS1DAGU3RJGLC2VGJJZZ09H7MBG--
|
