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 72095901
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 01:15:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com
[209.85.220.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E8ED0149
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Nov 2015 01:15:18 +0000 (UTC)
Received: by padhx2 with SMTP id hx2so39247796pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 Nov 2015 17:15:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent
:mime-version:content-type;
bh=N9XqxPKPC4S9ab8pdXjYKjNgZoieVSPHhE94SUIvyTs=;
b=E4OiyOi1Uq6NA8AAfZvbgwbErZJxZSp/TOwOeT2HnP8Juhdf4IBdnJ6Lu4cduy11G3
384igB1nBR6Ok9BoGgscxM+9RkgQ/uKay0ldF6ZwqTF0fT6f3pLfKlm1wOa2o8pJCKFZ
9mc8BBzDxawlupv9ZNoQrfUZH89UgVjxivaya6m+SxPH3vEOY4WmjfCAGjukwnzxwXIN
raZDMArc9+NGm5d+gtcZuq/2LJW8CdYYzxM3EBiHEr+d6uD27VLFdcj+xHc0PNm8hLvq
yxEN0TLXby6d8AeWU/PUlvS3zT1v+y28Yoam+fJ+yGIP5Rb6sdAter3LKHm0Oxr8+lmF
0Gcw==
X-Received: by 10.98.70.141 with SMTP id o13mr27723188pfi.44.1448414118658;
Tue, 24 Nov 2015 17:15:18 -0800 (PST)
Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
186sm16760534pfa.24.2015.11.24.17.15.17
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 24 Nov 2015 17:15:18 -0800 (PST)
From: "Eric Lombrozo" <elombrozo@gmail.com>
To: =?utf-8?q?Jorge=20Tim=c3=b3n?= <jtimon@jtimon.cc>, "Btc Drak"
<btcdrak@gmail.com>
Date: Wed, 25 Nov 2015 01:14:55 +0000
Message-Id: <em80f319b9-ff7c-4a88-85c7-efdb0333ada1@platinum>
In-Reply-To: <CABm2gDqoq4pkXLS=4rKGOLGU0_0mq1_yMOHmLw73m=apiMRMpg@mail.gmail.com>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF"
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
X-Mailman-Approved-At: Wed, 25 Nov 2015 01:23:53 +0000
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: Wed, 25 Nov 2015 01:15:19 -0000
--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From a system developer standpoint, CHECKMATURITYVERIFY ties together=20
the semantics of this opcode with another existing feature in the system=
=20
(coinbase maturity).
HOWEVER...
from an application developer standpoint, I think the concept of a=20
timelock is more relevant. Maturity is a concept that was introduced for=
=20
the sake of reducing the disruptive impact of reorgs. Miners would=20
prefer to be able to spend the coins immediately, but instead they are=20
forced to wait due to inherent limitations of the system. Timelocks, on=20
the other hand, are typically used to control when funds can be moved.=20
In these use cases, one or more of the parties involved explicitly want=20
there to be a delay even if there were an idealized situation in which=20
consensus is always reached instantaneously and there were never any=20
reorgs.
Moreover, since we already have CLTV, adding RCLTV or some variant=20
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=20
segregated witness it will be possible to add opcodes that can push=20
values onto the stack (rather than just hard failing or NOP), so there's=
=20
something to be said for naming consistency.
- Eric
------ Original Message ------
From: "Jorge Tim=C3=B3n" <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=20
(BIP112)
>I agree, I believe the first name that an op with equivalent=20
>functionality had was simply op_maturity.
>At least I remember we discussed such an opcode when discussing pegged=20
>sidechains' design.
>
>I kind of dislike the check_x_verify naming pattern. We want all new=20
>operands to return if whatever they're checking/verifying fails, fine.=20
>Do we have to repeat this redundant naming pattern forever due to that=20
>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=20
>become much more clear with this change.
>
--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<STYLE id=3DeMClientCss>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; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: 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=3Dauto class>
<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 somethin=
g 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=C3=B3n" <<A href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</A>></DIV>
<DIV>To: "Btc Drak" <<A href=3D"mailto:btcdrak@gmail.com">btcdrak@gmail.=
com</A>></DIV>
<DIV>Cc: "Bitcoin Dev" <<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.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=3Dxe40f4e1a28394eee96200b907d68005b>
<BLOCKQUOTE class=3Dcite2 cite=3DCABm2gDqoq4pkXLS=3D4rKGOLGU0_0mq1_yMOHmLw7=
3m=3DapiMRMpg@mail.gmail.com type=3D"cite">
<P dir=3Dltr>I agree, I believe the first name that an op with equivalent=
functionality had was simply op_maturity.<BR>At least I remember we discus=
sed such an opcode when discussing pegged sidechains' design.</P>
<P dir=3Dltr>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></BODY></HTML>
--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF--
|
