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
|
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 <tier.nolan@gmail.com>) id 1YxY8N-000873-9a
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:00:23 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.180 as permitted sender)
client-ip=209.85.220.180; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f180.google.com;
Received: from mail-qk0-f180.google.com ([209.85.220.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxY8M-0001HN-3i
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:00:23 +0000
Received: by qkhg32 with SMTP id g32so2347517qkh.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 03:00:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.132.17 with SMTP id 17mr21530271qhe.36.1432720816708;
Wed, 27 May 2015 03:00:16 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 27 May 2015 03:00:16 -0700 (PDT)
In-Reply-To: <CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
<20150527074713.GB22286@savin.petertodd.org>
<CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com>
Date: Wed, 27 May 2015 11:00:16 +0100
Message-ID: <CAE-z3OW29KpLzvD5-THOjQbL=5QH=1MRCA26FbN=6Bz80h0Nzg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c07c7257a29305170d4fd1
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
(tier.nolan[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: 1YxY8M-0001HN-3i
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 10:00:23 -0000
--001a11c07c7257a29305170d4fd1
Content-Type: text/plain; charset=UTF-8
This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced. A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
>
> It makes sequence numbers work exactly like you'd expect-- within the
> bounds of whats possible in a decentralized system. At the same time,
> all it is ... is relative nlocktime.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c07c7257a29305170d4fd1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>This could cause legacy transactions to become u=
nspendable.<br><br><br></div>A new transaction version number should be use=
d to indicate the change of the field from sequence number to relative lock=
time.<br><br></div>Legacy transactions should not have the rule applied to=
them.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <span dir=3D"ltr"><<a hr=
ef=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed,=
May 27, 2015 at 7:47 AM, Peter Todd <<a href=3D"mailto:pete@petertodd.o=
rg">pete@petertodd.org</a>> wrote:<br>
> Equally this proposal is no more "consensus enforcement" tha=
n simply<br>
> increasing the fee (and possibly decreasing the absolute nLockTime) fo=
r<br>
<br>
</span>You've misunderstood it, I think-- Functionally nlocktime but re=
lative<br>
to each txin's height.<br>
<br>
But the construction gives the sequence numbers a rational meaning,<br>
they count down the earliest position a transaction can be included.<br>
(e.g. the highest possible sequence number can be included any time<br>
the inputs are included) the next lower sequence number can only be<br>
included one block later than the input its assigned to is included,<br>
the next lower one block beyond that. All consensus enforced.=C2=A0 =C2=A0A=
<br>
miner could opt to not include the higher sequence number (which is<br>
the only one of the set which it _can_ include) it the hopes of<br>
collecting more fees later on the next block, similar to how someone<br>
could ignore an eligible locked transaction in the hopes that a future<br>
double spend will be more profitable (and that it'll enjoy that<br>
profit) but in both cases it must take nothing at all this block, and<br>
risk being cut off by someone else (and, of course, nothing requires<br>
users use sequence numbers only one apart...).<br>
<br>
It makes sequence numbers work exactly like you'd expect-- within the<b=
r>
bounds of whats possible in a decentralized system.=C2=A0 At the same time,=
<br>
all it is ... is relative nlocktime.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br></div>
--001a11c07c7257a29305170d4fd1--
|
