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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A376A04
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:21:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88FC91CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 16:21:45 +0000 (UTC)
Received: by wgjx7 with SMTP id x7so121623944wgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 09:21:44 -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=bCM518Zzy1c/Ec2QCnm1KFZfe87jHhaxnuIhjl5mCys=;
b=DNCLvR8J/zmSnKq6YxNgLNSoSwXMiswoRpiMeIMGTVla7giMNkBc45MDMRUlo25ufg
TV71aVF5i1EaCiiqWiQEsGF9K0ojiJMCpGMTOlqr9Tb972BVte6Tbf+BPrL0XluheHWA
aWqOmfSp/OhlNZh4T0gDnsen/LM9/zgT954uqxE/4Gm2fgwA6bOnDu/83WVKqgJ9PPs7
Em7qcOPjvmgZfYUEC2Tb74wU2YkoV01z0bEBK/OVRuIDN0hdlzrTW2C2mCIx38WPeq9z
3VveyZC0pmZUIlHJLm+/P/xwKqGs8YhXCSIYVoemNZ20LaPgHo7KcKVAZsdllwQGyPuW
aAvQ==
MIME-Version: 1.0
X-Received: by 10.194.100.42 with SMTP id ev10mr81898204wjb.50.1436113304173;
Sun, 05 Jul 2015 09:21:44 -0700 (PDT)
Received: by 10.195.12.166 with HTTP; Sun, 5 Jul 2015 09:21:44 -0700 (PDT)
Received: by 10.195.12.166 with HTTP; Sun, 5 Jul 2015 09:21:44 -0700 (PDT)
In-Reply-To: <CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com>
References: <55994696.1090705@thinlink.com>
<CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com>
Date: Sun, 5 Jul 2015 18:21:44 +0200
Message-ID: <CAPg+sBi_Q9heOQVtZHBOgweT5HrNRy7kPKQkok2VCE+0VaCd1Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e0160aa485a4522051a232f90
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@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:21:47 -0000
--089e0160aa485a4522051a232f90
Content-Type: text/plain; charset=UTF-8
I would say yes. Just putting a locktime in transaction may help against
fee sniping, even in transactions that are allowed to be mined at the same
time as some of their dependencies?
On Jul 5, 2015 6:17 PM, "Mark Friedenbach" <mark@friedenbach.org> 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> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e0160aa485a4522051a232f90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I would say yes. Just putting a locktime in transaction may =
help against fee sniping, even in transactions that are allowed to be mined=
at the same time as some of their dependencies?</p>
<div class=3D"gmail_quote">On Jul 5, 2015 6:17 PM, "Mark Friedenbach&q=
uot; <<a href=3D"mailto:mark@friedenbach.org">mark@friedenbach.org</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"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 c=
onfirmed 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" target=3D"_blank">tomh@thinlink.co=
m</a>> wrote:<br 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" target=3D"_blank">=
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>
<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>
<br></blockquote></div>
--089e0160aa485a4522051a232f90--
|
