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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1YzbL8-0002w5-4k
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Jun 2015 01:50:02 +0000
X-ACL-Warn:
Received: from mail-ig0-f176.google.com ([209.85.213.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzbL5-0002k7-0o
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Jun 2015 01:50:02 +0000
Received: by igbyr2 with SMTP id yr2so76373688igb.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 18:49:53 -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:from:date:message-id:subject:to
:content-type;
bh=5j/PyiVXYUmJYHFdM6L7rRw730hqaQ6pXO5NgJcFr4Q=;
b=Kw2CUl3n0e1LGACNenXfVcNgV1psrw1CK3EqbE8oqfqNbCdSOnfxRvvc3I3TLNd1yu
Hq35sr5hMiekTekDNQc5ZK2GClDymdiAMRg83+Nfer5NE5H3mlgH5E61w2H/9pMRz+HQ
UjoW9jtZLZBaI+BAOGwwHn6oBcJwzkYNpsJUH7VFVYGAKy1THfVzRoztRyAsXlv9iLq2
JSgVeO8ncaPH3fYIlln2o+G7A1qFyegW26DTeYUJ5JSy/C8yc4GDd3LyEuu0pljGejYn
ZwetZyXc/DVdb1lYzZrrDy6o1GG/F9kZ13HiVvqGABKyC7j3BvDzMKiVlP/iwfOocaMa
sbqg==
X-Gm-Message-State: ALoCoQleOLCJWtTIiBltLSuNPPYpNLHlHbCLC8300EPK5gjKeCfiE5Vxmg1iuy8xo6XIHq8gyVws
X-Received: by 10.43.40.130 with SMTP id tq2mr32435932icb.46.1433209793456;
Mon, 01 Jun 2015 18:49:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.197 with HTTP; Mon, 1 Jun 2015 18:49:33 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 1 Jun 2015 18:49:33 -0700
Message-ID: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51dd849a0c3c605177f2836
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: 1YzbL5-0002k7-0o
Subject: [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: Tue, 02 Jun 2015 01:50:02 -0000
--bcaec51dd849a0c3c605177f2836
Content-Type: text/plain; charset=UTF-8
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
--bcaec51dd849a0c3c605177f2836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I have written a reference implementation and BIP dra=
ft for a soft-fork change to the consensus-enforced behaviour of sequence n=
umbers 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:<br><br><a href=3D"http://sourceforge.net/p/bi=
tcoin/mailman/message/34146752/">http://sourceforge.net/p/bitcoin/mailman/m=
essage/34146752/</a><br><br></div><div>In short summary, this proposal seek=
s to enable safe transaction replacement by re-purposing the nSequence fiel=
d 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 range =
of the 32-bit sequence number which until now has rarely been used for anyt=
hing other than a boolean control over absolute nLockTime, and it does so i=
n a way that is semantically compatible with the originally envisioned use =
of sequence numbers for fast mempool transaction replacement.<br><br></div>=
<div>The disadvantages are that external constraints often prevent the full=
range of sequence numbers from being used when interpreted as a relative l=
ock-time, and re-purposing nSequence as a relative lock-time precludes its =
use in other contexts. The latter point has been partially addressed by hav=
ing the relative lock-time semantics be enforced only if the most-significa=
nt bit of nSequence is set. This preserves 31 bits for alternative use when=
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://gist.g=
ithub.com/maaku/be15629fe64618b14f5a">https://gist.github.com/maaku/be15629=
fe64618b14f5a</a><br><br></div><div>The reference implementation is availab=
le at the following git repository:<br></div><div><br><a href=3D"https://gi=
thub.com/maaku/bitcoin/tree/sequencenumbers">https://github.com/maaku/bitco=
in/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>
--bcaec51dd849a0c3c605177f2836--
|
