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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1Z51j7-0005wj-SD
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Jun 2015 01:01:13 +0000
X-ACL-Warn:
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z51j4-0007LF-SS
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Jun 2015 01:01:13 +0000
Received: by igbiq7 with SMTP id iq7so55994338igb.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Jun 2015 18:01:05 -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:from:date
:message-id:subject:to:content-type;
bh=mqTzfyTCK9hpOL65oNGxtU58KFX+9NLnQHc3ctn0zNM=;
b=Eau2PWybS6j1ggq2ZORo1Fz02QpoDq+kajfq0DoKZIWt1EjvmNeHy0kfyZqv+6pk63
6q57TzqWKfXaY27Nl+bXjQ/sBwWyPcxDGY+aK5HObTi2LirMMYiN3KNsR7c6OPLak8GN
sWQiQN9Q21gTCsgV2sDsS5MPzBij8vcpaQf+qyU0bY9NZirP5dohmHg4fFnB0MHIP3vD
P8zX3nlZI/NkRoLDpBAMY8SypIvQ6N75hCuqDMy2FV1FE9NCkRHuynkj/yIcQRNT7ohe
I0JBaBi4RE+qiJ2R/SrFiMdFhamb53ZZSoZDixTB4jb0FSpbrwysZZSrPqTQfPXjH2aH
XF7g==
X-Gm-Message-State: ALoCoQlAJHB/6sP2YYiBkxBJjVh3miI6VS1Xo/a2pm1E5LWAveHwFjG5uIQ+CW23wv/nMljO5heU
X-Received: by 10.43.40.130 with SMTP id tq2mr6014105icb.46.1434502865427;
Tue, 16 Jun 2015 18:01:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.149.20 with HTTP; Tue, 16 Jun 2015 18:00:45 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 16 Jun 2015 18:00:45 -0700
Message-ID: <CAOG=w-s5D2eaF0biPEEeFgLKLNpA3ho1Sk4mCPQNpVOeNBgr-A@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51dd849b957010518ac3949
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z51j4-0007LF-SS
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced
transaction replacement signalled via sequence numbers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2015 01:01:13 -0000
--bcaec51dd849b957010518ac3949
Content-Type: text/plain; charset=UTF-8
Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process to
proceed?
Thank you,
Mark Friedenbach
On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replacement via per-input relative
> lock-times. This proposal was previously discussed on the mailing list in
> the following thread:
>
> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>
> In short summary, this proposal seeks to enable safe transaction
> replacement by re-purposing the nSequence field of a transaction input to
> be a consensus-enforced relative lock-time.
>
> The advantages of this approach is that it makes use of the full range of
> the 32-bit sequence number which until now has rarely been used for
> anything other than a boolean control over absolute nLockTime, and it does
> so in a way that is semantically compatible with the originally envisioned
> use of sequence numbers for fast mempool transaction replacement.
>
> The disadvantages are that external constraints often prevent the full
> range of sequence numbers from being used when interpreted as a relative
> lock-time, and re-purposing nSequence as a relative lock-time precludes its
> use in other contexts. The latter point has been partially addressed by
> having the relative lock-time semantics be enforced only if the
> most-significant bit of nSequence is set. This preserves 31 bits for
> alternative use when relative lock-times are not required.
>
> The BIP draft can be found at the following gist:
>
> https://gist.github.com/maaku/be15629fe64618b14f5a
>
> The reference implementation is available at the following git repository:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> I request that the BIP editor please assign a BIP number for this work.
>
> Sincerely,
> Mark Friedenbach
>
--bcaec51dd849b957010518ac3949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Given that we have had more than two weeks of pu=
blic discussion, code is available and reviewed, and several community iden=
tified issues resolved, I would like to formally request a BIP number be as=
signed for this work. Will the BIP editor be so kind as to do so to allow t=
he BIP consensus process to proceed?<br><br></div>Thank you,<br></div>Mark =
Friedenbach<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <span dir=3D"ltr"><=
<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.=
org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>I have written a reference implementation and BIP draft for a soft-f=
ork change to the consensus-enforced behaviour of sequence numbers for the =
purpose of supporting transaction replacement via per-input relative lock-t=
imes. This proposal was previously discussed on the mailing list in the fol=
lowing thread:<br><br><a href=3D"http://sourceforge.net/p/bitcoin/mailman/m=
essage/34146752/" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailma=
n/message/34146752/</a><br><br></div><div>In short summary, this proposal s=
eeks to enable safe transaction replacement by re-purposing the nSequence f=
ield of a transaction input to be a consensus-enforced relative lock-time.<=
br><br>The advantages of this approach is that it makes use of the full ran=
ge of the 32-bit sequence number which until now has rarely been used for a=
nything other than a boolean control over absolute nLockTime, and it does s=
o in a way that is semantically compatible with the originally envisioned u=
se of sequence numbers for fast mempool transaction replacement.<br><br></d=
iv><div>The disadvantages are that external constraints often prevent the f=
ull range of sequence numbers from being used when interpreted as a relativ=
e lock-time, and re-purposing nSequence as a relative lock-time precludes i=
ts use in other contexts. The latter point has been partially addressed by =
having the relative lock-time semantics be enforced only if the most-signif=
icant bit of nSequence is set. This preserves 31 bits for alternative use w=
hen relative lock-times are not required.<br></div><div><br></div><div>The =
BIP draft can be found at the following gist:<br><br><a href=3D"https://gis=
t.github.com/maaku/be15629fe64618b14f5a" target=3D"_blank">https://gist.git=
hub.com/maaku/be15629fe64618b14f5a</a><br><br></div><div>The reference impl=
ementation is available at the following git repository:<br></div><div><br>=
<a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers" target=3D=
"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers</a><br><br><=
/div><div>I request that the BIP editor please assign a BIP number for this=
work.<br><br></div><div>Sincerely,<br></div><div>Mark Friedenbach<br></div=
></div>
</blockquote></div><br></div>
--bcaec51dd849b957010518ac3949--
|
