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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 79BE1411
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 16:37:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF7EA8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 16:37:14 +0000 (UTC)
Received: from mail-io0-f178.google.com ([209.85.223.178]) by
mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id
0LescD-1aM7b30Okx-00qj9U for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 18:37:14 +0200
Received: by iofl186 with SMTP id l186so96086546iof.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 09:37:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.15.27 with SMTP id x27mr11794305ioi.51.1444927033176;
Thu, 15 Oct 2015 09:37:13 -0700 (PDT)
Received: by 10.50.85.135 with HTTP; Thu, 15 Oct 2015 09:37:13 -0700 (PDT)
In-Reply-To: <CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com>
References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au>
<20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au>
<CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com>
<CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com>
Date: Thu, 15 Oct 2015 18:37:13 +0200
Message-ID: <CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:DtLCTkX3o3ReyNqtSGbDhEB+vGXPSWk1CNfmr/9tQ2gXMIa1+M8
QxjIdOQrL/xT9/r3866XL4dWwd6c5+hoNM5mm1p2SHgCLIU/i1ndq/Aluqd9Fd4+SpQ3pPS
+CefUJMo17z5D0Jaz86nmpVUXncEkQA+0pFJ4oZ65slLbpoESAFlDKqUI+s6OK4ONapGJam
a1Pcs7qz3ot5NVlLEmRAQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:eKEXch5IsZ0=:VONBqvAIxZzcQtxkVNkRUR
b1I2RSDKgWfziJEnjCrGoG2NiZx2Ag2uGKjVTyZrNBZxh8+7zFE+IeQiQzle35SOEdzXdePNS
HJqLvzW+NmjKUGh3EtTRKIQhtmapGflLVGACLnkW5Dhyr8le7XSYED0h2P2rq/o7qARkcGtNw
DHSiHWvxCtj5BvRMxVayyUp71ceYFAGIFWqTo0c6NLOjGl7pDyE4J4JDgjB8Cf7isuGzmTJNc
3XlqtkZ8QS0w7SBtACFDLW7wIemGrggGThl+1p/p9nj5spbp1JVjN3BVTIqevsXlBmVNmvMNz
gLUXzbQMbdLNIrsgmwvzqDEPkLa/GD3FDsohhUHb8V4/QE+PDyxKCS2IhYfKd9ppwEB13CXuJ
/FSN0MkVwKI6y1ZyxYqHh9uwBLzFD6J09i1q+63x1Qjh6Ip4ajlBb+SwJy9HoNg3XUhXKslL2
4yRP5c9g6mBVCZf1TQyRHDzI/zdfjiVK/YbcyUBNrmOzUgLx6wms5GuTnJLkMGgQ6290XhTP9
2ohGS2kNNegN2fkKBZHA53x8dJ6543KkkcRuV73htx6NhdAuQeTJokHYibn8+uvHxkfTO/5ap
oAABvUzWxDn2vZtdWW0cH4XhZbGSxk/Vg5OnxSoFg7WecVnvS6RidbutM+nOyIWwpV5A1rq1P
wXts7FQ4uI9naP5YFiW2n44sp7CDWcsQ4vX6MdM8HSkvo4Q==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
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] CHECKSEQUENCEVERIFY - We need more usecases to
motivate the change
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, 15 Oct 2015 16:37:15 -0000
Does that pre-judge that block interval would never change from
10mins? Eg say with IBLT or fountain codes etc and security arguments
for the current limitations of them are found, such that orphan rates
can remain low in a decentralised way with 1min blocks, then the
locktime granularity would be coarse relative to the block interval
(with 512s locktime granularity.
Adam
On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
> a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> SEQUENCE_LOCKTIME_GRANULARITY in the PR
> https://github.com/bitcoin/bitcoin/pull/6312.
>
> /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> * applied to extract that lock-time from the sequence field. */
> static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
>
> /* In order to use the same number of bits to encode roughly the
> * same wall-clock duration, and because blocks are naturally
> * limited to occur every 600s on average, the minimum granularity
> * for time-based relative lock-time is fixed at 512 seconds.
> * Converting from CTxIn::nSequence to seconds is performed by
> * multiplying by 512 = 2^9, or equivalently shifting up by
> * 9 bits. */
> static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
>
> I am also much happier with this last tightening up of the specification
> because it removes ambiguity. 512s granularity makes sense within the
> context of the 10 minute block target.
>
> Thank you for spending so much time carefully considering this BIP and
> reference implementation and please let me know if there there are any
> remaining nits so we can get those addressed.
>
>
>
>
>
> On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Mark,
>>
>> You seemed interested in changing BIP 68 to use 16 bits for sequence
>> number in both the block and time versions, making time based sequence
>> numbers have a resolution of 512 seconds.
>>
>> I'm in favor of this approach because it leaves aside 14 bits for further
>> soft forks within the semantics of BIP 68.
>>
>> It would be nice to know if you're planning this change, and perhaps
>> people can hold off on review until things are finalized.
>>
>> I'd cast my "vote" against BIP 68 without this change, but am also open to
>> being convinced otherwise.
>>
>> What are other peoples opinions on this?
>>
>> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> Peter Todd <pete@petertodd.org> writes:
>>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>> >> writes:
>>> >> > However I don't think we've done a good job showing why we need to
>>> >> > implement this feature via nSequence.
>>> >>
>>> >> It could be implemented in other ways, but nSequence is the neatest
>>> >> and
>>> >> most straightforward I've seen.
>>> >>
>>> >> - I'm not aware of any other (even vague) proposal for its use?
>>> >> Enlighten?
>>> >
>>> > There's three that immediately come to mind:
>>> >
>>> > Gregory Maxwell has proposed it as a way of discouraging miners from
>>> > reorging chains, by including some of the low-order bits of a previous
>>> > block header in nSequence.
>>> >
>>> > A few people have proposed implementing proof-of-stake blocksize voting
>>> > with nSequence.
>>>
>>> Excellent, thanks! It's good to have such ideas as a compass. PoS
>>> voting seems like it won't be a problem in 5 bits.
>>>
>>> The "prevbits" idea would want more bits; naively 64 would be good, but
>>> I think there are some tricks we can use to make 32 work OK. We would
>>> have to then split between nLocktime (if available) and multiple
>>> nSequence fields, and it would weaken it for some txs.
>>>
>>> There is one easy solution: change the BIP wording from:
>>>
>>> -For transactions with an nVersion of 2 or greater,
>>> +For transactions with an nVersion of 2,
>>>
>>> And on every tx bump, we decide whether to keep this scheme (mempool
>>> would enforce it always).
>>>
>>> Cheers,
>>> Rusty.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
