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
|
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 C7B47BF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2015 22:08:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
[209.85.213.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C046812E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2015 22:08:52 +0000 (UTC)
Received: by igcse8 with SMTP id se8so25298578igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2015 15:08:52 -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:from:date
:message-id:subject:to:cc:content-type;
bh=RnxmZfp8UD1DFEFCcjH3ywZJxl9r9sj83Mb0oYNI4cE=;
b=Cb1GBpgaijCcjnj519DRebNR/mdY6+Mj3/JWW425dSl8VaXH5K1K0EM8PD6YUfIl9o
f61vdbf2qkbXuWe0wK5BfakhGirJvxXHzROfiqfPpisqRuHm9kgdJFtxqXdGEtk60xDC
zzTiJ16/U3i2Iv08dgc/llLlCczuPocDVfMmDuwydg4FAFNUMb9c5JP5csVU+CCUwVlS
7X//lekUumiOKoNWf1lYGxUuRbmxPaQh4H4q8mf40QIHSI8znQFrNFhIeJ59m6cJ1Mwi
K2/RCHnuGLoSEfThE9PWUO/xbnP3IV7vatOUaZs5PZtBhW4KR8NxJCgBapCG8zls+iG9
8eHg==
X-Gm-Message-State: ALoCoQnbshFPkcFsfMICJEDPGjRIx2YaGPqVl16Z8NVmT90Qb4c2EezAhc/8AASXVYGAWnWfUi4z
X-Received: by 10.50.102.4 with SMTP id fk4mr6872498igb.46.1440540532167; Tue,
25 Aug 2015 15:08:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.138.14 with HTTP; Tue, 25 Aug 2015 15:08:32 -0700 (PDT)
X-Originating-IP: [24.4.96.213]
In-Reply-To: <CAOG=w-ubk3nPfxy25Hd6kPeehf7vnYD5chksLWU5wU2t=jL5TA@mail.gmail.com>
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>
<CABm2gDqW7OGuyZ1BTTeeivDf9wFVsAK9AaGYm8XWwLb2O2Lb+g@mail.gmail.com>
<CAOG=w-ubk3nPfxy25Hd6kPeehf7vnYD5chksLWU5wU2t=jL5TA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 25 Aug 2015 15:08:32 -0700
Message-ID: <CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=047d7b11198db4c03d051e29facb
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: Tue, 25 Aug 2015 22:08:53 -0000
--047d7b11198db4c03d051e29facb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
To follow up on this, let's say that you want to be able to have up to 1
year relative lock-times. This choice is somewhat arbitrary and what I
would like some input on, but I'll come back to this point.
* 1 bit is necessary to enable/disable relative lock-time.
* 1 bit is necessary to indicate whether seconds vs blocks as the unit of
measurement.
* 1 year of time with 1-second granularity requires 25 bits. However since
blocks occur at approximately 10 minute intervals on average, having a
relative lock-time significantly less than this interval doesn't make much
sense. A granularity of 256 seconds would be greater than the Nyquist
frequency and requires only 17 bits.
* 1 year of blocks with 1-block granularity requires 16 bits.
So time-based relative lock time requires about 19 bits, and block-based
relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
other uses.
Assuming a maximum of 1-year relative lock-times. But what is an
appropriate maximum to choose? The use cases I have considered have only
had lock times on the order of a few days to a month or so. However I would
feel uncomfortable going less than a year for a hard maximum, and am having
trouble thinking of any use case that would require more than a year of
lock-time. Can anyone else think of a use case that requires >1yr relative
lock-time?
TL;DR
On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> A power of 2 would be far more efficient here. The key question is how
> long of a relative block time do you need? Figure out what the maximum
> should be ( I don't know what that would be, any ideas?) and then see how
> many bits you have left over.
> On Aug 23, 2015 7:23 PM, "Jorge Tim=C3=B3n" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > 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.
>>
>> No, I don't think anybody thought about this. I just explained this to
>> Pieter using "for example, 10 instead of 1".
>> He suggested 600 increments so that it is more similar to timestamps.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
--047d7b11198db4c03d051e29facb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>To follow up on this, let's say that you wan=
t to be able to have up to 1 year relative lock-times. This choice is somew=
hat arbitrary and what I would like some input on, but I'll come back t=
o this point.<br><br></div><div>=C2=A0* 1 bit is necessary to enable/disabl=
e relative lock-time.<br></div><div><br></div><div>=C2=A0* 1 bit is necessa=
ry to indicate whether seconds vs blocks as the unit of measurement.<br><br=
></div><div>=C2=A0* 1 year of time with 1-second granularity requires 25 bi=
ts. However since blocks occur at approximately 10 minute intervals on aver=
age, having a relative lock-time significantly less than this interval does=
n't make much sense. A granularity of 256 seconds would be greater than=
the Nyquist frequency and requires only 17 bits.<br><br></div><div>=C2=A0*=
1 year of blocks with 1-block granularity requires 16 bits.<br></div><div>=
<br></div>So time-based relative lock time requires about 19 bits, and bloc=
k-based relative lock-time requires about 18 bits. That leaves 13 or 14 bit=
s for other uses.<br><br></div><div>Assuming a maximum of 1-year relative l=
ock-times. But what is an appropriate maximum to choose? The use cases I ha=
ve considered have only had lock times on the order of a few days to a mont=
h or so. However I would feel uncomfortable going less than a year for a ha=
rd maximum, and am having trouble thinking of any use case that would requi=
re more than a year of lock-time. Can anyone else think of a use case that =
requires >1yr relative lock-time?<br></div><div><br></div>TL;DR <br></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Aug 23,=
2015 at 7:37 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:=
mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</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"><p dir=3D"ltr">A power of 2 would=
be far more efficient here. The key question is how long of a relative blo=
ck time do you need? Figure out what the maximum should be ( I don't kn=
ow what that would be, any ideas?) and then see how many bits you have left=
over.</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On Aug 23, 2015 7:23 PM, "Jorge Tim=C3=B3n&=
quot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D=
"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 24, 2015 at 3:01 A=
M, Gregory Maxwell via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<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>
No, I don't think anybody thought about this. I just explained this to<=
br>
Pieter using "for example, 10 instead of 1".<br>
He suggested 600 increments so that it is more similar to timestamps.<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>
</div></div></blockquote></div><br></div>
--047d7b11198db4c03d051e29facb--
|
