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
|
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 E38E2FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 02:54:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 292221F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 02:54:35 +0000 (UTC)
Received: by igfj19 with SMTP id j19so51928277igf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Aug 2015 19:54:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=wfay3smOtbm1FU0NFECH22E6ItjXmsfQQZHmmriXR0Q=;
b=azRMi5KNLPJ5Sjk4xR45OitR3oaDg74kbu4SKDLdzXxkyRTX/XVqTyxOREfipXynrV
ifX6T39SCPQqE8C21rGn1gk508BH4crUS9eMgvIoNtVyZigH4HsYERe70+8tTYtRrIWK
9cf8n5TbaqlsR8VF4y0I2N8lpG5GwErbYVkrthP8xLP+nSrkzdZONJQsm0WVxxLBK7jw
N8qOf+LHrRcZoCnFP4b5p0lZH2sxExVmlMa9RRHYTM24qYB98m/q/yCu/lOu7cLI3QVm
VA9Dblun+fN9vGoon6VBEhXLzSqOQ+Yfbet4i1kHYGzcvGKv8qKmeE4dqdoepfq0YV3S
boGw==
X-Gm-Message-State: ALoCoQkN6PXQhH0souFKyf60OcDhB1TzoKa6kX8Jhml4aQXLz2FLfbqkadPhMlauTs0iCvW//3Kx
MIME-Version: 1.0
X-Received: by 10.50.129.5 with SMTP id ns5mr12798647igb.40.1440384874667;
Sun, 23 Aug 2015 19:54:34 -0700 (PDT)
Received: by 10.107.138.14 with HTTP; Sun, 23 Aug 2015 19:54:34 -0700 (PDT)
X-Originating-IP: [172.56.30.71]
Received: by 10.107.138.14 with HTTP; Sun, 23 Aug 2015 19:54:34 -0700 (PDT)
In-Reply-To: <85537faedb1e601d243e3edb666fa844@xbt.hk>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
<CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com>
<CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com>
<CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com>
<55DA6470.9040301@thinlink.com>
<CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com>
<85537faedb1e601d243e3edb666fa844@xbt.hk>
Date: Sun, 23 Aug 2015 19:54:34 -0700
Message-ID: <CAOG=w-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=047d7b3a9914cb77bd051e05bcfd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
relative locktime
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: Mon, 24 Aug 2015 02:54:36 -0000
--047d7b3a9914cb77bd051e05bcfd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sorry this was meant for the list:
There are only 32 bits in the version field. If you're going to spend a bit
for perpetuity to indicate whether or not a feature is active, you'd better
have a good reason to make that feature optional.
I haven't seen a compelling use case for having BIP 68 be optional in that
way. As you note, BIP 68 semantics is already optional by toggling the most
significant bit, and that doesn't permanently burn a version bit.
On Aug 23, 2015 7:41 PM, "jl2012 via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Gregory Maxwell via bitcoin-dev =E6=96=BC 2015-08-23 21:01 =E5=AF=AB=E5=
=88=B0:
>
>
>> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>> discussion has any thought been given to represent one block with more
>> than one increment? This would leave additional space for future
>> signaling, or allow, for example, higher resolution numbers for a
>> sharechain commitement.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> I think this comment is more related to BIP68 instead of OP_CSV? Without
> further complicating the BIP68, I believe the best way to leave room for
> improvement is to spend a bit in tx nVersion to indicate the activation o=
f
> BIP68. I have raised this issue before with
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043=
.html
> However, it seems Mark isn't in favor of my proposal
>
> The idea is not to permanently change the meaning of nSequence. Actually,
> BIP68 is "only enforced if the most significant bit of the sequence numbe=
r
> field is set." So BIP68 is optional, anyway. All I suggest is to move the
> flag from nSequence to nVersion. However, this will leave much bigger roo=
m
> for using nSequence for other purpose in the future.
>
> AFAIK, nSequence is the only user definable and signed element in TxIn.
> There could be more interesting use of this field and we should not chang=
e
> its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 byte=
s,
> it could be used to indicate the value of the input to fix this problem:
> https://bitcointalk.org/index.php?topic=3D181734.0 )
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--047d7b3a9914cb77bd051e05bcfd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Sorry this was meant for the list:</p>
<p dir=3D"ltr">There are only 32 bits in the version field. If you're g=
oing to spend a bit for perpetuity to indicate whether or not a feature is =
active, you'd better have a good reason to make that feature optional.<=
/p>
<p dir=3D"ltr">I haven't seen a compelling use case for having BIP 68 b=
e optional in that way. As you note, BIP 68 semantics is already optional b=
y toggling the most significant bit, and that doesn't permanently burn =
a version bit.</p>
<div class=3D"gmail_quote">On Aug 23, 2015 7:41 PM, "jl2012 via bitcoi=
n-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Gregory Maxwell via bitcoin-dev =E6=96=BC 20=
15-08-23 21:01 =E5=AF=AB=E5=88=B0:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the<br>
discussion has any thought been given to represent one block with more<br>
than one increment?=C2=A0 This would leave additional space for future<br>
signaling, or allow, for example, higher resolution numbers for a<br>
sharechain commitement.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote>
<br>
I think this comment is more related to BIP68 instead of OP_CSV? Without fu=
rther complicating the BIP68, I believe the best way to leave room for impr=
ovement is to spend a bit in tx nVersion to indicate the activation of BIP6=
8. I have raised this issue before with <a href=3D"http://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2015-August/010043.html" rel=3D"noreferrer" =
target=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
15-August/010043.html</a> However, it seems Mark isn't in favor of my p=
roposal<br>
<br>
The idea is not to permanently change the meaning of nSequence. Actually, B=
IP68 is "only enforced if the most significant bit of the sequence num=
ber field is set." So BIP68 is optional, anyway. All I suggest is to m=
ove the flag from nSequence to nVersion. However, this will leave much bigg=
er room for using nSequence for other purpose in the future.<br>
<br>
AFAIK, nSequence is the only user definable and signed element in TxIn. The=
re could be more interesting use of this field and we should not change its=
meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes, it=
could be used to indicate the value of the input to fix this problem: <a h=
ref=3D"https://bitcointalk.org/index.php?topic=3D181734.0" rel=3D"noreferre=
r" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D181734.0</a>=
)<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--047d7b3a9914cb77bd051e05bcfd--
|
