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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 56A63143C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 07:43:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60AD0AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 07:43:04 +0000 (UTC)
Received: from localhost ([::1]:32904 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZcTqQ-0016Jq-SR; Thu, 17 Sep 2015 03:43:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 17 Sep 2015 03:43:02 -0400
From: jl2012@xbt.hk
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@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>
<CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com>
<CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com>
Message-ID: <52804bf0fb44a77efb3610e6bdf978e4@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Thu, 17 Sep 2015 07:43:05 -0000
How many years of relative lock time do we need? It really depends why
we need a relative lock time in the first place, what what does it offer
in addition to CHECKLOCKTIMEVERIFY. The only case I know is when the
confirmation taking too long, CLTV may expire before the tx is
confirmed. For use case like this, 1 year of relative lock time is much
more than enough, since Bitcoin is basically worthless if it takes
months to confirm a tx with a reasonable fee.
Is there any other use case of CSV that is irreplaceable by CLTV? There
is only one example in the BIP CSV draft.
For the timebased relative lock time, 256 seconds of granularity is more
than enough since the block interval is 600s. Although it is not
impossible to reduce the block interval in the future, that will be a
hardfork anyway and we may just hardfork BIP68/CSV at the same time.
Mark Friedenbach via bitcoin-dev 於 2015-08-27 19:32 寫到:
> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers2 [2]
>
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means
> 1 second relative lock-height. nSequence>=0x80000000 (most significant
> bit set) is not interpreted as a relative lock-time.
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers3 [3]
>
> This repository not only inverts the sequence number, but also
> interprets it as a fixed-point number. This allows up to 5 year
> relative lock times using blocks as units, and saves 12 low-order bits
> for future use. Or, up to about 2 year relative lock times using
> seconds as units, and saves 4 bits for future use without second-level
> granularity. More bits could be recovered from time-based locktimes by
> choosing a higher granularity (a soft-fork change if done correctly).
>
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach
> <mark@friedenbach.org> wrote:
>
>> 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ón"
>> <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 [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] https://github.com/maaku/bitcoin/tree/sequencenumbers2
> [3] https://github.com/maaku/bitcoin/tree/sequencenumbers3
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
