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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1YxQUk-0007f4-MC
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 01:50:58 +0000
X-ACL-Warn:
Received: from mail-ig0-f182.google.com ([209.85.213.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxQUg-0005ux-S6
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 01:50:58 +0000
Received: by igbpi8 with SMTP id pi8so75022774igb.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 May 2015 18:50:49 -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=LG4CuOXgVWHsB7jKHXHm+veI6jJlWXflF2kMsL68D+Q=;
b=g01VlBirESgU6uoEH7j2AD1z2Q3enCZ8Rh3WAAsXhxR/Xbd4wnB8JLWzxUS3/uskMS
whfp+QYBlmVjIG1bhFGEV1uaVhd0A8sU4h8gS6eX3K9AVy3cpXsF8KvGDwUI/mEwr/fi
JonCkyrcnKp0E2hWOrGMZmHIwtftzrR6kBncK5VzE2MI8yuVXUG2BW9AS0QX/7V38Nfl
ZbpOyj/iwI59gOMbmmPXjjpXGwYwkEaGKpdrAyF2H27LcmEyXsudWYfigPovkfbtl9ZS
wioTdhN7aqI0xOYlZ/vsjGNvFVrSS6E3STM5Mk33wnSyVG9tjyWBodrq5h0MPCzKkF3X
84yg==
X-Gm-Message-State: ALoCoQnHfc2V1/3xDsGun06qvUkSnUbaMCWGUwLHgz0YTOjVX13oRu4dP/LOMK3LzbcApS7R/iZ9
X-Received: by 10.107.17.17 with SMTP id z17mr39064913ioi.76.1432691449445;
Tue, 26 May 2015 18:50:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.197 with HTTP; Tue, 26 May 2015 18:50:29 -0700 (PDT)
X-Originating-IP: [172.56.9.144]
From: Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 26 May 2015 18:50:29 -0700
Message-ID: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113ed46ceaf001051706788b
X-Spam-Score: 2.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
1.0 UC_GIBBERISH_OBFU Multiple instances of "word VERYLONGGIBBERISH
word"
X-Headers-End: 1YxQUg-0005ux-S6
Subject: [Bitcoin-development] Consensus-enforced transaction replacement
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, 27 May 2015 01:50:58 -0000
--001a113ed46ceaf001051706788b
Content-Type: text/plain; charset=UTF-8
Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
sequence field by some amount. Relay nodes perform transaction replacement
according to some policy rule making use of the sequence numbers, e.g.
requiring sequence numbers in a replacement to be monotonically increasing.
As it happens, this cannot be made safe in the bitcoin protocol as deployed
today, as there is no enforcement of the rule that miners include the most
recent transaction in their blocks. As such, any protocol relying on a
transaction replacement policy can be defeated by miners choosing not to
follow that policy, which they may even be incentivised to do so (if older
transactions provide higher fee per byte, for example). Transaction
replacement is presently disabled in Bitcoin Core.
These shortcomings can be fixed in an elegant way by giving sequence
numbers new consensus-enforced semantics as a relative lock-time: if a
sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
as either a relative height or time delta which is added to the height or
median time of the block containing the output being spent to form a
per-input lock-time. The lock-time of each input constructed in this manor,
plus the nLockTime of the transaction itself if any input is non-final must
be satisfied for a transaction to be valid.
For example, a transaction with an txin.nSequence set to 0xffffff9b [==
~(uint32_t)100] is prevented by consensus rule from being selected for
inclusion in a block until the 100th block following the one including the
parent transaction referenced by that input.
In this way one may construct, for example, a bidirectional micropayment
channel where each change of direction increments sequence numbers to make
the transaction become valid prior to any of the previously exchanged
transactions.
This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
implemented in the same way: by checking transaction data only and not
requiring contextual information like the block height or timestamp.
An example implementation of this concept, as a policy change to the
mempool processing of Bitcoin Core is available on github:
https://github.com/maaku/bitcoin/tree/sequencenumbers
--001a113ed46ceaf001051706788b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sequence numbers appear to have been originally intended a=
s a mechanism for transaction replacement within the context of multi-party=
transaction construction, e.g. a micropayment channel. The idea is that a =
participant can sign successive versions of a transaction, each time increm=
enting the sequence field by some amount. Relay nodes perform transaction r=
eplacement according to some policy rule making use of the sequence numbers=
, e.g. requiring sequence numbers in a replacement to be monotonically incr=
easing.<br><br>As it happens, this cannot be made safe in the bitcoin proto=
col as deployed today, as there is no enforcement of the rule that miners i=
nclude the most recent transaction in their blocks. As such, any protocol r=
elying on a transaction replacement policy can be defeated by miners choosi=
ng not to follow that policy, which they may even be incentivised to do so =
(if older transactions provide higher fee per byte, for example). Transacti=
on replacement is presently disabled in Bitcoin Core.<br><br>These shortcom=
ings can be fixed in an elegant way by giving sequence numbers new consensu=
s-enforced semantics as a relative lock-time: if a sequence number is non-f=
inal (MAX_INT), its bitwise inverse is interpreted as either a relative hei=
ght or time delta which is added to the height or median time of the block =
containing the output being spent to form a per-input lock-time. The lock-t=
ime of each input constructed in this manor, plus the nLockTime of the tran=
saction itself if any input is non-final must be satisfied for a transactio=
n to be valid.<br><br>For example, a transaction with an txin.nSequence set=
to 0xffffff9b [=3D=3D ~(uint32_t)100] is prevented by consensus rule from =
being selected for inclusion in a block until the 100th block following the=
one including the parent transaction referenced by that input.<br><br>In t=
his way one may construct, for example, a bidirectional micropayment channe=
l where each change of direction increments sequence numbers to make the tr=
ansaction become valid prior to any of the previously exchanged transaction=
s.<br><br>This also enables the discussed relative-form of CHECKLOCKTIMEVER=
IFY to be implemented in the same way: by checking transaction data only an=
d not requiring contextual information like the block height or timestamp.<=
br><br>An example implementation of this concept, as a policy change to the=
mempool processing of Bitcoin Core is available on github:<br><br><a href=
=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers">https://github.c=
om/maaku/bitcoin/tree/sequencenumbers</a><br></div>
--001a113ed46ceaf001051706788b--
|
