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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <lemientelephone@gmail.com>) id 1YxWK0-0001zN-AJ
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 08:04:16 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.173 as permitted sender)
client-ip=209.85.213.173;
envelope-from=lemientelephone@gmail.com;
helo=mail-ig0-f173.google.com;
Received: from mail-ig0-f173.google.com ([209.85.213.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxWJy-0005fu-JC
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 08:04:16 +0000
Received: by igbsb11 with SMTP id sb11so8039027igb.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 01:04:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.29.148 with SMTP id d142mr41513649iod.9.1432713849285;
Wed, 27 May 2015 01:04:09 -0700 (PDT)
Received: by 10.64.16.229 with HTTP; Wed, 27 May 2015 01:04:09 -0700 (PDT)
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
Date: Wed, 27 May 2015 10:04:09 +0200
Message-ID: <CAL6tygZbYOXh3bS50ejwS6aynhuxu2xCoAOV9Fb7hfLu-4RFpA@mail.gmail.com>
From: Telephone Lemien <lemientelephone@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a114089c40d333105170bb049
X-Spam-Score: 3.3 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(lemientelephone[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YxWJy-0005fu-JC
Subject: Re: [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 08:04:16 -0000
--001a114089c40d333105170bb049
Content-Type: text/plain; charset=UTF-8
Please remove me from the mailing list
2015-05-27 3:50 GMT+02:00 Mark Friedenbach <mark@friedenbach.org>:
> 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
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a114089c40d333105170bb049
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Please remove me from the mailing list<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-05-27 3:50 GMT+02:00 M=
ark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.or=
g" target=3D"_blank">mark@friedenbach.org</a>></span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Sequence numbers appear to have been orig=
inally intended as a mechanism for transaction replacement within the conte=
xt of multi-party transaction construction, e.g. a micropayment channel. Th=
e idea is that a participant can sign successive versions of a transaction,=
each time incrementing the sequence field by some amount. Relay nodes perf=
orm transaction replacement according to some policy rule making use of the=
sequence numbers, e.g. requiring sequence numbers in a replacement to be m=
onotonically increasing.<br><br>As it happens, this cannot be made safe in =
the bitcoin protocol as deployed today, as there is no enforcement of the r=
ule that miners include the most recent transaction in their blocks. As suc=
h, any protocol relying on a transaction replacement policy can be defeated=
by miners choosing not to follow that policy, which they may even be incen=
tivised to do so (if older transactions provide higher fee per byte, for ex=
ample). Transaction replacement is presently disabled in Bitcoin Core.<br><=
br>These shortcomings can be fixed in an elegant way by giving sequence num=
bers new consensus-enforced semantics as a relative lock-time: if a sequenc=
e number is non-final (MAX_INT), its bitwise inverse is interpreted as eith=
er a relative height or time delta which is added to the height or median t=
ime 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 nLoc=
kTime of the transaction itself if any input is non-final must be satisfied=
for a transaction to be valid.<br><br>For example, a transaction with an t=
xin.nSequence set to 0xffffff9b [=3D=3D ~(uint32_t)100] is prevented by con=
sensus rule from being selected for inclusion in a block until the 100th bl=
ock following the one including the parent transaction referenced by that i=
nput.<br><br>In this way one may construct, for example, a bidirectional mi=
cropayment channel where each change of direction increments sequence numbe=
rs to make the transaction become valid prior to any of the previously exch=
anged transactions.<br><br>This also enables the discussed relative-form of=
CHECKLOCKTIMEVERIFY to be implemented in the same way: by checking transac=
tion data only and not requiring contextual information like the block heig=
ht or timestamp.<br><br>An example implementation of this concept, as a pol=
icy change to the mempool processing of Bitcoin Core is available on github=
:<br><br><a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers" =
target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers</a>=
<br></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a114089c40d333105170bb049--
|
