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
201
202
203
204
205
206
207
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F3B0E282
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 13:47:34 +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 F3968144
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 13:47:33 +0000 (UTC)
Received: by igbni9 with SMTP id ni9so14340037igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 06:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=d4iMrFPWTzr1bv+eEXwLM/FcyFyqWj6Ykvcs86+4m64=;
b=kUfOpTNm3xyg0niz5cg87NWkcXRAwFtxmgUCunSeINtmRmwkRW2LltjhhqVVP+nnCj
AbzchpLsweLK7GuqDQI/zzJTBNRH/MiClu8Q0pRM88xiZ9WnaT/jamVdFS545XS786qJ
KzweQ8wg8o7qv02X1LA62auN4uV7T8t5o/kcVRwIwzzzFRYYCdqXQFAENDXI0b3DBbPP
NpCwc/DthtbYQZH4YCDIvjnOWv+scQLv0cAKpAkhEaioBVFWCzX+bNBLHK9/Tm1qZVhf
yBipb66mh9MBl8Jh9g+XDYn6bJQNZOwxVtNHH0pRghPLipTe5stSvFJTYTWimTwAzmbA
CFtg==
MIME-Version: 1.0
X-Received: by 10.50.111.83 with SMTP id ig19mr10140328igb.82.1444916853425;
Thu, 15 Oct 2015 06:47:33 -0700 (PDT)
Received: by 10.64.25.80 with HTTP; Thu, 15 Oct 2015 06:47:33 -0700 (PDT)
In-Reply-To: <87pp0okeip.fsf@rustcorp.com.au>
References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au>
<20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au>
Date: Thu, 15 Oct 2015 09:47:33 -0400
Message-ID: <CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=089e013d0bf2c74a90052224eb9c
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
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 13:47:35 -0000
--089e013d0bf2c74a90052224eb9c
Content-Type: text/plain; charset=UTF-8
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
>
--089e013d0bf2c74a90052224eb9c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mark,=C2=A0<div><br><div>You seemed interested in changing=
BIP 68 to use 16 bits for sequence number in both the block and time versi=
ons, making time based sequence numbers have a resolution of 512 seconds.</=
div></div><div><br></div><div>I'm in favor of this approach because it =
leaves aside 14 bits for further soft forks within the semantics of BIP 68.=
=C2=A0</div><div><br></div><div>It would be nice to know if you're pla=
nning this change, and perhaps people can hold off on review until things a=
re finalized.</div><div><br></div><div>I'd cast my "vote" aga=
inst BIP 68 without this change, but am also open to being convinced otherw=
ise.</div><div><br></div><div>What are other peoples opinions on this?</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oc=
t 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr"><<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><span class=3D"">Peter Todd <<a href=3D"mailto:pete@pe=
tertodd.org">pete@petertodd.org</a>> writes:<br>
> On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:<br>
>> Peter Todd via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>><br>
>> writes:<br>
>> > However I don't think we've done a good job showing w=
hy we need to<br>
>> > implement this feature via nSequence.<br>
>><br>
>> It could be implemented in other ways, but nSequence is the neates=
t and<br>
>> most straightforward I've seen.<br>
>><br>
>> - I'm not aware of any other (even vague) proposal for its use=
?=C2=A0 Enlighten?<br>
><br>
> There's three that immediately come to mind:<br>
><br>
> Gregory Maxwell has proposed it as a way of discouraging miners from<b=
r>
> reorging chains, by including some of the low-order bits of a previous=
<br>
> block header in nSequence.<br>
><br>
> A few people have proposed implementing proof-of-stake blocksize votin=
g<br>
> with nSequence.<br>
<br>
</span>Excellent, thanks!=C2=A0 It's good to have such ideas as a compa=
ss.=C2=A0 PoS<br>
voting seems like it won't be a problem in 5 bits.<br>
<br>
The "prevbits" idea would want more bits; naively 64 would be goo=
d, but<br>
I think there are some tricks we can use to make 32 work OK.=C2=A0 We would=
<br>
have to then split between nLocktime (if available) and multiple<br>
nSequence fields, and it would weaken it for some txs.<br>
<br>
There is one easy solution: change the BIP wording from:<br>
<br>
-For transactions with an nVersion of 2 or greater,<br>
+For transactions with an nVersion of 2,<br>
<br>
And on every tx bump, we decide whether to keep this scheme (mempool<br>
would enforce it always).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Cheers,<br>
Rusty.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
</div></div></blockquote></div><br></div>
--089e013d0bf2c74a90052224eb9c--
|
