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
|
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 9F08BA04
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:25:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com
[209.85.220.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C3421CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:25:17 +0000 (UTC)
Received: by pactm7 with SMTP id tm7so82245622pac.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 09:25:16 -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=2Qs9+6CMn+U4iJqs/FpC4MVhyfl7AH43Z7Yb+qt9ugo=;
b=Zc1Mc/DxplfDDlEtr5zv8EpvjpStc5RppVxA62qB3wmemE0ThnLgk5lFzwOKXlT6by
5tPmHHxiX4ao4LeGbWHi5DQ0oMplzoaJuKEgqad2+4ZcnNhQ6CU8BkklE20AhOJlwY7W
7Zdnz+Lr4l+hZ1IgRS/r55ywGi7cnZScyl3r3l/iXRbm2HGWMrrjkQWZIdUtBx5+x3+w
42jqxsIiAT/BgHZX6pqXX1wN4mX6Qesc9raaseHxKmxVhzh0b+a1ZVISuHNklSmDH+KH
Gc9tzcGp43YWlkJbaI4RF3PejTl6WDfCPrfg7sEZc6rjFnPyN+N5LKpu+nCwxHX6wgkd
VLlw==
X-Gm-Message-State: ALoCoQk5op6aDpg+9KQ6p54a3ehEzMx9GxLYercGkTtNF2zJZZDOMPJY9BYMXUUqaPR7Z3TltzoS
X-Received: by 10.66.229.65 with SMTP id so1mr96386681pac.92.1436113516650;
Sun, 05 Jul 2015 09:25:16 -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
ml6sm15325306pdb.69.2015.07.05.09.25.14
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 05 Jul 2015 09:25:14 -0700 (PDT)
Message-ID: <55995A6D.8090703@thinlink.com>
Date: Sun, 05 Jul 2015 09:25:17 -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-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com>
In-Reply-To: <CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------020504080806030408030003"
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 16:25:17 -0000
This is a multi-part message in MIME format.
--------------020504080806030408030003
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Since you're removing a working capability, you should be the one to
prove it is unneeded.
But the simple example is the case where the input is also locked.
On 7/5/2015 9:17 AM, Mark Friedenbach wrote:
>
> Can you construct an example? Are there use cases where there is a
> need for an enforced lock time in a transaction with inputs that are
> not confirmed at the time the lock time expires?
>
> On Jul 5, 2015 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
>
--------------020504080806030408030003
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">
Since you're removing a working capability, you should be the one to
prove it is unneeded.<br>
<br>
But the simple example is the case where the input is also locked.<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/5/2015 9:17 AM, Mark Friedenbach
wrote:<br>
</div>
<blockquote
cite="mid:CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com"
type="cite">
<p dir="ltr">Can you construct an example? Are there use cases
where there is a need for an enforced lock time in a transaction
with inputs that are not confirmed at the time the lock time
expires?</p>
<div class="gmail_quote">On Jul 5, 2015 8:00 AM, "Tom Harding"
<<a moz-do-not-send="true" href="mailto:tomh@thinlink.com">tomh@thinlink.com</a>>
wrote:<br type="attribution">
<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>
</blockquote>
<br>
</body>
</html>
--------------020504080806030408030003--
|
