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
|
Return-Path: <tomh@thinlink.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D290B1D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 19:50:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com
[209.85.192.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8593F1C2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 19:50:57 +0000 (UTC)
Received: by pdjd13 with SMTP id d13so93158730pdj.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 12:50:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type;
bh=eRzh9IKHFFEHwJ1JS+sZuFrlitd64S3ytOjTZk0pg/E=;
b=j80idiHdDg03qoogqSe8hE1DvTCzFFZCG0OHpEDwzJ92M8dhpTvf3PhIcS//TS0jHf
Keut2HNsrvMA42+UXRLxmZZuVzQuiHifZe4deiGMB553WzyX3IEHlpAhdv3FBK9qWS1I
/8nraGATVPRmhxC8BFQfpCGqfS1yrxjIdjf4MdNKjlQeVe2CwMk35nwF58sYL89Fdl+/
/dEJnPl0qTYdYbKZDb/Eka2kvfId+CYNqhpLZv8nLu8fY1CKBhTWNsUxGvegvfFUkRew
BgaOSYJezHua+damaCqlnwLh7Z+gkjqdD8Ll79IKDL5UY/V7MU2TSsMyVBJMqoPlDL6D
2joQ==
X-Gm-Message-State: ALoCoQmLolv/FkXxR7woizKPHQzt8T4qlIz/laH76eTXqqYsa3AWjc9ISB9MsciWyo1wgi0JviML
X-Received: by 10.68.229.40 with SMTP id sn8mr96727822pbc.59.1436125857200;
Sun, 05 Jul 2015 12:50:57 -0700 (PDT)
Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net.
[99.8.65.117]) by mx.google.com with ESMTPSA id
bn5sm15658039pbc.82.2015.07.05.12.50.55
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 05 Jul 2015 12:50:55 -0700 (PDT)
Message-ID: <55998AA3.4060801@thinlink.com>
Date: Sun, 05 Jul 2015 12:50:59 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Mark Friedenbach <mark@friedenbach.org>
References: <55994696.1090705@thinlink.com>
<CAOG=w-t+VCk66mM1N1Pc4PN2T9=X94hhyg_Pc+2_ULT51JfxCA@mail.gmail.com>
In-Reply-To: <CAOG=w-t+VCk66mM1N1Pc4PN2T9=X94hhyg_Pc+2_ULT51JfxCA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010806040100030708050205"
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
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: Sun, 05 Jul 2015 19:50:58 -0000
This is a multi-part message in MIME format.
--------------010806040100030708050205
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Or you could flip the definition of your activation bit. That would
avoid the inversion and put relative locktimes outside the realm of both
the MAX_INT and MAX_INT - 1 values.
It would also allow an explicit relative locktime of 0, which would help
applications avoid accidentally finalizing the whole transaction when
they only meant to not impose a relative locktime on one input.
On 7/5/2015 10:07 AM, Mark Friedenbach wrote:
> Note that you can put 0 in the sequence number field and it would work
> just as expected under the old rules. I will perhaps suggest instead
> that Bitcoin Core post-0.11 switch to doing this instead for that case.
>
> On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh@thinlink.com
> <mailto:tomh@thinlink.com>> wrote:
>
> BIP 68 uses nSequence to specify relative locktime, but nSequence also
> continues to condition the transaction-level locktime.
>
> This dual effect will prevent a transaction from having an effective
> nLocktime without also requiring at least one of its inputs to be
> mined
> at least one block (or one second) ahead of its parent.
>
> The fix is to shift the semantics so that nSequence = MAX_INT - 1
> specifies 0 relative locktime, rather than 1. This change will also
> preserve the semantics of transactions that have already been created
> with the specific nSequence value MAX_INT - 1 (for example all
> transactions created by the bitcoin core wallet starting in 0.11).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--------------010806040100030708050205
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Or you could flip the definition of your activation bit. That would
avoid the inversion and put relative locktimes outside the realm of
both the MAX_INT and MAX_INT - 1 values.<br>
<br>
It would also allow an explicit relative locktime of 0, which would
help applications avoid accidentally finalizing the whole
transaction when they only meant to not impose a relative locktime
on one input.<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/5/2015 10:07 AM, Mark Friedenbach
wrote:<br>
</div>
<blockquote
cite="mid:CAOG=w-t+VCk66mM1N1Pc4PN2T9=X94hhyg_Pc+2_ULT51JfxCA@mail.gmail.com"
type="cite">
<div dir="ltr">Note that you can put 0 in the sequence number
field and it would work just as expected under the old rules. I
will perhaps suggest instead that Bitcoin Core post-0.11 switch
to doing this instead for that case.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jul 5, 2015 at 8:00 AM, Tom
Harding <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tomh@thinlink.com" target="_blank">tomh@thinlink.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">BIP 68
uses nSequence to specify relative locktime, but nSequence
also<br>
continues to condition the transaction-level locktime.<br>
<br>
This dual effect will prevent a transaction from having an
effective<br>
nLocktime without also requiring at least one of its inputs
to be mined<br>
at least one block (or one second) ahead of its parent.<br>
<br>
The fix is to shift the semantics so that nSequence =
MAX_INT - 1<br>
specifies 0 relative locktime, rather than 1. This change
will also<br>
preserve the semantics of transactions that have already
been created<br>
with the specific nSequence value MAX_INT - 1 (for example
all<br>
transactions created by the bitcoin core wallet starting in
0.11).<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>
--------------010806040100030708050205--
|
