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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6ACF79FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:17:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B76C61BF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:17:20 +0000 (UTC)
Received: by ieqy10 with SMTP id y10so100661232ieq.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 09:17:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Exb75tJq5y1xvvB5pafI7M2QiBsTRB0H8V+QBXsb8oo=;
b=mPujDfPLhi0ftrV2o9L53rplpdX5MeGEVvAaaYVrx5gC7djQSG3Lbx2FXHl6wYuVDe
rCSxz+YFrYpGwje7WKvPShUUaFs6t62fht3R2RACjqdbkSu35zsy7NJnr9qOnXXrncIA
+lGud+FrroVTchQwoqz/lms9PqbiEVA9BdsY88PMR7BJkfLe0/E9dnRljiNlt9Gkh6He
VCCh6gfqaFzuVfC5p3C3ceuAzC4OmzVSe7LMDvevNeGhyBpNXHIw0SkIeMuJkMZMGthg
T/hG5OkoPzituQkljAU1nl+FJ+phwShzaYzu2WWQv6pmH2i2MfhIbfx1KJ6hSaaRfehE
MLzQ==
X-Gm-Message-State: ALoCoQlJJCJjpbqRVYOvZEPXZ0L4/B+v+psUxq2/WlgFrH2ZDxP5FTBo9Nw8ptZW0ICEj3i8VTyT
MIME-Version: 1.0
X-Received: by 10.42.105.16 with SMTP id t16mr30201670ico.40.1436113039992;
Sun, 05 Jul 2015 09:17:19 -0700 (PDT)
Received: by 10.107.8.104 with HTTP; Sun, 5 Jul 2015 09:17:19 -0700 (PDT)
X-Originating-IP: [172.56.16.163]
Received: by 10.107.8.104 with HTTP; Sun, 5 Jul 2015 09:17:19 -0700 (PDT)
In-Reply-To: <55994696.1090705@thinlink.com>
References: <55994696.1090705@thinlink.com>
Date: Sun, 5 Jul 2015 09:17:19 -0700
Message-ID: <CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=20cf303f64ca9b42b3051a231f0b
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:17:21 -0000
--20cf303f64ca9b42b3051a231f0b
Content-Type: text/plain; charset=UTF-8
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> 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--20cf303f64ca9b42b3051a231f0b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Can you construct an example? Are there use cases where ther=
e 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=3D"gmail_quote">On Jul 5, 2015 8:00 AM, "Tom Harding" =
<<a href=3D"mailto:tomh@thinlink.com">tomh@thinlink.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"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 =3D MAX_INT - 1<br>
specifies 0 relative locktime, rather than 1.=C2=A0 This change will also<b=
r>
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 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>
</blockquote></div>
--20cf303f64ca9b42b3051a231f0b--
|
